Дано: МК AT91SAM7S в качестве USBD.
Реализовано устройство класса USB Audio Device спецификации 1.0 с
довольно простой аудиофункцией (out terminal).

1) Я правильно понял, что имея ограничение максимальной длины пакета 64 байта
в режиме USBD_FS/isochnonous мы никогда не сможем прокачать по ОДНОМУ data enpoint данные
со скоростью выше, чем 64*1000 = 64KBps? Ехарный бабай!
Так какого фига тогда на всех углах Атмел кричит, что они поддерживают USB 2.0 в семействе SAM7S?
Они поддерживают с очень серьезными ограничениями по скорости.
USBD_FS это должно быть 1023*1000=1023KBps в изохронном режиме.
Как по мне о таком ограничении надо просто кричать на первых страницах даташита.

2) Исходя из ограничений, описанных в п.1 получаю максимальный сэмплрейт для TYPE I/PCM/16bit/2канала 16000KHz.
Что конечно же обидно т.к. мало-мальски качественный звук - это хотябы от 24 килосэмплов.
Не долго думая я захотел обойти это ограничения ценой потери одного канала. В соотв. дескрипторе
поменял число каналов на 1 (TYPE I/PCM/16bit/1канал), но моя WINDOWS XP/SP3 не захотела работать с таким устройством.
Дальше - больше: при попытке заявить конфигурацию TYPE I/PCM/8bit/2канала/1 байт на субаудиофрейм WINDOWS стабильно уходит
в BSOD. Собственно вопрос: а что при описании аудиофункции для ОС WINDOWS существуют какие то негласные
бизнесправила? Например в процессе отладки я насчитал ДНЕСЯТКИ конфигураций, удовлетворяющих USB Audio Devices Class 1.0, но
стабильно посылающие Виндоуз в BSOD Себя перепроверял много раз - ошибки в дескрипторах нет.
Я дурак или виндоуз глючная?

3) На чем дальше вести разработку? Мне необходимо передавать/принимать аудиопотоки с сэмплрейтами 96 и 192 Ksps.
Поэтому надо будет выжать из USBD_FS практически все соки
Делать мост МК-FTDI? Или может есть какой то другой дешевый МК с ARM ядром, поддерживающий USB 2.0 _полностью_?

На LPC2148 (с USB 2.0) и подключенном через SSP кодеке PCM3002 я получал PCM 16 бит 2 канала 48 кГц sample rate.
20 бит тоже работало - но я вернулся на 16 - мне было достаточно.
Для повышения качества и уменьшения джиттера отказался от адаптивного тактирования и поставил внешний генератор для кодека. С записью проблем нет, с воспроизведением - нужно большой буффер для устранения кратких (но редких) перерывов в воспроизведении - виновата винда. Но - производительность не очень, лучше брать процессоры с встроенным I2S (типа LPC2368)
Обсуждалось начало разработки на
http://electronix.ru/forum/index.php?showt...3&hl=lebiga

Спасибо

Почитал. Ну ребята, знаете... такая охренительная динамика и интермодуляционные искажения нужна разве что применительно к
связной радиолюбительской аппаратуре. Нафига эта погоня за пикосекундным джитером применительно к звуку я не понимаю.
Особенно, если учесть, что большинство таких любителей хи-фи не способны в слепом тесте отличить звучание девайсов диаметрально противоположного класса.

Ну это все лирика.

У меня при попытке выставить pcm/2канала/1байт/8бит винда падает в BSOD.
Это как то обходится?

Кстати, а вариант написать свой драйвер, который бы доставлял аудиоконтент в режиме BULK? Кто то реализовывал? Если ссылки на проект?

Сообщение отредактировал ua_97346 - Apr 9 2009, 15:08

Но там же не один endpoint.
По 3-м прекрасно прокачается PCM 16/2/48 Кгц
Или я не прав?

Сообщение отредактировал Kris2007 - Apr 22 2009, 10:11

Количество endpoint не увеличит пропускную способность канала USB.

Погоня за джиттером - это для измерения качества звукоизоляции, данные получаюся с микрофонов и считаются спектры.
Теперь о проблемах... Какая винда? Кабель какой применяется - USB2.0?
pcm/2канала/1байт/8бит - не понял, какая частота дискретизации? Чем проверяется устройство?
У меня в самом начале разработки PCM 1 канал 16 бит 48кгц (768 kbps) работал с загрузкой процессора около 55% - воспроизведение через винамп
Потом уже дописал и на 2 канала + управление через другие endpoint

USB 2.0 еще не значит High Speed автоматом.

USB блок LPC214x и выше ограничений на изохронный режим передачи не имеет. В презентациях NXP на ограничения USB блоков конкурентов всегда указывается

Да, это понятно.

Просто FS это полоса ~12M.
Ну, допустим в изохронном режиме никто не собирается утилизировать всю полосу.
Но хотябы 50-70% от полосы надо ведь дать?

А у них получается всего 64 KBps = 512 Kbps.

ИМХО на таком факте надо акцентировать внимание т.к. это резко сужает применяемость решения в некоторых
задачах.

Ну да ладно. Из SAM7 выжал давно все соки. Все работает как надо.
Но та же самая задача. С поправкой на сегодня.

Вот думаю что лучше:
Взять какой-нибудь процессор ARM/Cortex-M3 с поддержкой USB/FS/max isochronous?
Или не мучаться и поставить специализированную микросхему для USB интерфейса типа 13-го сайпруса ?
В сайпрусе "пугает" необходимость доп интерфейсинга и программинг USB на дополнительном процессоре.



Да вот как раз Кортекс от NXP рассматриваю как вариант.
Но там правда нет поддержки USB::HS.
USB::HS есть только в ATMEL-овском SAM3U, но что то на него пока демо бордов нейти не могу.
А самому из сэмплов макетницу делать так ломает...

Сообщение отредактировал ua_97346 - Dec 14 2009, 09:24