Сделал я одно устройство типа генератора сигнала - измерения отклика на LPC2148 и кодеке PCM3002. Частота дискретизации определяется внешним кварцевым генератором, сигнал которого подается на таймер-счетчик в LPC2148, он генерирует сигналы для кодека. Кодек подключен к LPC на SPI1 в 16 разрядном режиме. Проект построен на IAR USB Audio Device, он оказался наиболее полным (и ввод, и вывод). Возникла проблема, бьюсь уже несколько недель - генерация сигнала искажается через каждые 20с на 1-2 сек. Увеличение буффера помогает немного - искажения возникают реже, но не исчезают, так как в этом проекте генерация начинается только после заполнения буффера на 2/3. Адаптивный режим (как в исходном проекте) отключил (не устраивает! ), прерывания fiq происходят регулярно синхронно с частотой дискретизации кодека. Подозреваю - причина в том, что скорость поступления данных по USB меньше, чем вывожу в кодек. Искал по форуму (http://electronix.ru/forum/index.php?showtopic=20117&hl=), изучал стандарты - audio10.pdf (с usb.org), пробовал различные режимы - не получается. Может подскажете чего-нибуть, или объясните, как настроить правильно USB дескрипторы и задержки в них , использовать ли синхронный режим?
Вот дескрипторы интерфейса 1 - генерация сигнала (Speaker в проекте)

// Interface 1
// AudioStreaming Interface Descriptor
// Zero-bandwidth Alternate Setting 0
// Standard AS Interface Descriptor
sizeof(UsbStandardInterfaceDescriptor_t),
UsbDescriptorInterface,
1,
0,
0,
UsbDeviceClassAudio,
AUDIOSTREAMING,
PR_PROTOCOL_UNDEFINED,
0,

// Operational Alternate Setting 1
// Standard AS Interface Descriptor
sizeof(UsbStandardInterfaceDescriptor_t),
UsbDescriptorInterface,
1,
1,
1,
UsbDeviceClassAudio,
AUDIOSTREAMING,
PR_PROTOCOL_UNDEFINED,
0,

// Class-specific AS General Interface Descriptor
sizeof(UsbClassSpecificASInterfaceDescriptor_t),
CS_INTERFACE,
AS_GENERAL,
SpkInTermID,
2,
_2BL(PCM),

// USB Spk Type I Format Type Descriptor
sizeof(UsbTypeIFormatTypeDescriptor_t)+ 3,
CS_INTERFACE,
FORMAT_TYPE,
FORMAT_TYPE_I,
1,
SubFrameSize,
8*SubFrameSize,
1,
(Int8U)(SampFreq),(Int8U)(SampFreq>>8),(Int8U)(SampFreq>>16),

// USB SPK Standard Endpoint Descriptor
sizeof(StandardASEndpointDescriptor_t),
UsbDescriptorEp,
UsbEpOut(SpkEp>>1),
// (Int8U)UsbEpTransferIsochronous + (Int8U)UsbEpSynchAdaptive,
(Int8U)UsbEpTransferIsochronous + (Int8U)UsbEpSynchAsynchronous,
_2BL(SpkEpMaxSize),
1,
0,
0,

// USB SPK Class-specific Isoc. Audio Data Endpoint Descriptor
sizeof(ClassSpecASEndpointDescriptor_t),
CS_ENDPOINT,
EP_GENERAL,
0,
0,
_2BL(0),

На память попытаюсь написать, т.к. в свое время пытался вникнуть в режимы USB. Для такого режима, когда частота кодека не подстраивается под метки USB, нужен асинхронный изохронный режим, который не поддерживается (прямо это нигде не написано, но поиском находил сообщение об этом от авторов) драйверами USB audio в WinXP.

Поддерживается, зависит от драйверов, писали- нужно доустановить QFE для USB2.0, если не установлено драйверами для чипсета. Это и все другое для USB AUDIO обсуждалось на
http://electronix.ru/forum/index.php?showtopic=1202&hl=
и на
http://electronix.ru/forum/index.php?showtopic=20117&hl=
Увеличение буффера помогает, но немного, через каждые 30-40сек все равно есть провалы.

Alex11 писал:

может кто подскажет, как настроить такой режим?

Я эти темы читал, даже одна из них моя :-)
А как реализована подстройка размера пакета?
Есть управляющий обратный канал?
Про QFE не слышал, там что-то изменено в отношении USB-audio?
Мне показалось, что это патч для USB системы

Размер пакета вроде не меняется, 96 байт. Это проект иара AudioDevice (\ARM\EXAMPLES\NXP\LPC214x\AudioDevice)
Управление стандартное - интерфейс 0 (регуляторы), дополнительного интерфейса не делал. Мне казалось, что это управление это по умолчанию??? или как?

Тут надо немного теории. Для аудио используется изохронный тип передачи. Для него есть 3 типа синхронизации: адаптивный, синхронный и асинхронный.

адаптивный - подстраивает свою частоту под поток данных. Так работает пример из иара (насколько я помню);

синхронный - подстраивает свою частоту под частоту USB кадров;

асинхронный - приемник должен ЯВНО указывать хосту какой размер кадра ему надо передавать, чтобы избежать переполнения/опустошения буфера. Для этого надо создать еще одну конечную точку обратной связи и с ее помощью информировать хост об изменении размера кадра. Более подробно (но тоже немного) можно прочитать, например, в книге Агурова и спецификации USB :-) .

Спасибо, я и использовал асинхронный, только не знал, каким образом делать обратную связь, думал, что тики юсб можно подстроить. Может поделитесь каким - нибуть примером, как посылать запрос на изменение размера буффера? Агурова нашел, изучаю. Спецификацию audio10.pdf с Audio Device тоже имею.

К сожалению, я сам не дошел до реального воплощения, т.к. задумывалось все только ради интереса, а интерес стимул слабый. Т.е. только собрал плату с голым 2148 и на этом все :-( .
Если продвинитесь дальше :-) просьба поделиться знаниями. Но насколько следует из Агурова (а у него похоже перевод спецификации, т.к. почти слово в слово этот же текст читал у другого автора), добавить обратный канал несложно, проблемы в указанной выше ветке были в том, что аудио-дрова не очень хорошо отрабатывали команды изменения буфера. Хотя в принципе да, у человека оно работало.

А что скажете на счет идеи забить на виндовые приколы и ориентироваться на USBASIO? Вроде он универсальный под все профессиональные USB audio устройства. И с синхронизацией и размером данных там проблем нет. Кто-нибудь видел спецификацию протокола, или прийдется устраивать реверс-инжиниринг?

Я думаю это ничего не изменит, нас прежде всего ограничивает спецификация USB audio, а не Винда (если действительно в SP2 появилась нормальная поддержка асинхронного режима).

Теперь по теме топика. Согласно литературе, для случая когда есть синхронные источник и приемник (lebiga это Ваш случай, насколько я понял проект), то по идеи хватит того, чтобы и у источника, и у приемника были одинаковые номера точек, но разные направления, и у источника (т.е. Ваш канал записи) в байте аттрибутов значение бит [5:4]=10 (т.е. данные с предоставлением неявной обратной связи). Тогда, согласно спецификации, хост будет определять скорость поступления данных от источника в соответствии с поступлением фактических данных от приемника. Попробуйте, интересно что получится.

Это описано только в стандарте audio20 Final, audio10 я этого не нашел. Не уверен, что проект на иаре полностью поддерживает этот стандарт, да и я сейчас пока работаю на лицензионной WIN2000 (а там этого точно нет). Проверю на XP, сообщу, что получилось.

Так вроде от устройства ничего и не требуется. Хост должен сам определить по номерам точек и аттрибутам битов, что канал используется как неявный обратный. Необходимо, кроме указанного выше, чтобы обе точки были изохронными, что в проекте уже установлено + асинхронны.
В общем ждем результатов, правда как распознать, в случае если не выйдет, кто виноват, винда или аудио девайс я не представляю.

вот, нашел в инете:
">Does MacOSX tiger USB audio driver really support async iso endpoint with feedback now ?

We developed USB audio codec (AK4570) with the above protocol about six years ago.
Howver, the AK4570 didn't work well under both of MacOSX and Windows 2000.
Pop noise occurred because FIFO buffer became full or empty.
Only Linux supported at that time.

Recently I tested the device again and I found that it worked well under Windows XP.
However, I remember that it didn't still worked well under MacOSX Tiger."

Что-то с неявной обратной связью не получается, в атрибутах задал 10 = Implicit feedback Data endpoint, номера точек одинаковые, только не понимаю - как задать, по какой точке синхронизировать.

Агуров пишет:
Для точек, требующих обратной связи, в некоторых случаях можно избежать
выделения в устройстве специальной точки обратной связи, используя не-
неявную обратную связь (implicit feedback). Это возможно, если в устройстве
есть группа функционально-связанных изохронных точек, работающих от
общего генератора синхронизации, и среди них есть точка с направлением,
противоположным точке, требующей явной обратной связи. Если требуется
обратная связь для асинхронного приемника, то информация неявной об-
обратной связи берется из скорости передачи данных синхронизированного с
ним передатчика. Аналогично для адаптивного источника информация не-
неявной обратной связи берется из скорости синхронизированного с ним при-
приемника. Конечная точка данных, которую можно использовать как источ-
источник неявной обратной связи, в байте атрибутов bmAttributes имеет
значение бит [5:4] = 10 (см. разд. 4.1.3). Связи по синхронизации в группе
устанавливаются на основе номеров точек. Для того чтобы найти источник
неявной обратной связи для какой-либо точки, ищется изохронная точка
противоположного направления с таким же или меньшим номером, имею-
имеющая в байте атрибутов биты [5:4] = 10.

Работаю с аудио через waveAudio API - DELPHI7
Присутствуют разрывы в выводимом сигнале - данные заканчиваются
Кто может еще чего посоветовать?

У обеих точек стоит тип синхронизации - асинхронный?

Да, асинхронный изохронный
...
// USB SPK Standard Endpoint Descriptor
sizeof(StandardASEndpointDescriptor_t),
UsbDescriptorEp,
UsbEpOut(SpkEp>>1), // EP3, out
(Int8U)UsbEpTransferIsochronous + (Int8U)UsbEpSynchAsynchronous + (Int8U)UsbEpUsageImplicit,
_2BL(SpkEpMaxSize),
1,
0,
0,
...

// USB MIC Standard Endpoint Descriptor
sizeof(StandardASEndpointDescriptor_t),
UsbDescriptorEp,
UsbEpIn(MicEp>>1), // EP3, in
(Int8U)UsbEpTransferIsochronous + (Int8U)UsbEpSynchAsynchronous + (Int8U)UsbEpUsageImplicit,
_2BL(MicEpMaxSize),
1,
0,
0,
...
опорная должна быть USB MIC
может номер точки аудио нужно перенести на большую - изохронная в lpc2148 следующая №6 логическая (физическая 12)

А если сделать стерео воспроизведение и запись - как нужно добавлять конечные точки ? или интерфейсы?