LPC2148 + USB Audio Device + кодек PCM3002, проблемы с выводом - рассинхронизация Опции

[lebiga]

Сделал я одно устройство типа генератора сигнала - измерения отклика на 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),

[khach]

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

[nikkov]

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

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

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

[lebiga]

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

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

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

[nikkov]

Не уверен, что проект на иаре полностью поддерживает этот стандарт

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

вот, нашел в инете:
">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."