USB Audio, как проще сделать? Опции

[Atlantis-]

Здравствуйте!
Нужно передавать речь с микрофона компьютера на устройство по USB, в устройстве STM32F429. Как я понимаю, основная проблема в несовпадении частоты дискретизации на компьютере и в устройстве. Как обычно решается эта проблема? Какие должны быть размеры буфера в устройстве?
Добавлю, что нужно использовать Bulk передачи, поэтому прямо взять готовое решение не могу.

Сообщение отредактировал Atlantis- - Jun 27 2018, 14:49

[DmitryM]

Здравствуйте!
Нужно передавать речь с микрофона компьютера на устройство по USB, в устройстве STM32F429. Как я понимаю, основная проблема в несовпадении частоты дискретизации на компьютере и в устройстве. Как обычно решается эта проблема? Какие должны быть размеры буфера в устройстве?
Добавлю, что нужно использовать Bulk передачи, поэтому прямо взять готовое решение не могу.

Isochoronous Endpoint

[Atlantis-]

Isochoronous Endpoint

Я же говорю, у меня Bulk и поменять не могу

[uriy]

Я же говорю, у меня Bulk и поменять не могу

Тогда причем тут несовпадение частоты дискретизации?

[jcxz]

Я же говорю, у меня Bulk и поменять не могу

Тогда и передавать поток реального времени не можете.

[Rst7]

Тогда и передавать поток реального времени не можете.

Кто ж Вам такое сказал?

[jcxz]

Кто ж Вам такое сказал?

Спецификация USB.

[uriy]

Тогда и передавать поток реального времени не можете.

RTP можно накинуть

[jcxz]

RTP можно накинуть

На что накинуть?

[Atlantis-]

Тогда причем тут несовпадение частоты дискретизации?

При любом типе передачи эту проблему надо как то разруливать, вопрос как.

Тогда и передавать поток реального времени не можете.

Почему? Поток данных небольшой, теоретически могу позволить себе буфер хоть на две секунды

RTP можно накинуть

Это что, протокол реального времени?

[Genadi Zawidowsk...]

Простой алгоритм ресэмплинга (по размер очереди буферов) вставкой - выкидыванием выборок есть тут - https://188.134.5.254/browser/hfreceiver/trunk/buffers.c функция buffers_resample

https://188.134.5.254/browser/hfreceiver/tr...buffers.c#L1005

[jcxz]

Почему? Поток данных небольшой, теоретически могу позволить себе буфер хоть на две секунды

Потому что bulk не гарантирует полосы передачи. В данный момент может всю полосу отдать, а через секунду, рядом, на этом же USB-хабе, другое устройство начало данные гнать - и полоса bulk делится между всеми устройствами на хабе. А ещё хуже если в этот же хаб воткнули устройство с изохронной точкой с рамером кадра близким к максимальному - оно займёт почти всю полосу передачи и все bulk-и будут делить оставшиеся крохи (или несколько устройств с активными изохронными точками в сумме забирающими почти всю полосу).
Как выше уже сказали: только изохронная точка гарантирует полосу передачи. Потому как уже при активации профиля, системный USB-драйвер сразу проверяет "есть ли достаточная полоса для работы изохронной точки?" и если есть - резервирует эту полосу, не давая её занять другим точкам, а если нет - сразу даёт отлуп о невозможности активации профиля.
Ну может ещё interrupt, не знаю - надо смотреть. Всё остальное будет работать от случая к случаю - как повезёт, а значит - нельзя использовать для реал-тайм потоков.

[mantech]

При любом типе передачи эту проблему надо как то разруливать, вопрос как.

Предварительное заполнение буферов, переключение буферов и выборка из них с соотв. частотой. Нужно будет выбрать необходимый размер буфера (чем больше, тем дольше время заполнения, но меньше вероятность "квакания" и прочих артефактов). Но не забывайте, что звук на выходе будет отставать на время заполнения буферов.

[jcxz]

(чем больше, тем дольше время заполнения, но меньше вероятность "квакания" и прочих артефактов).

С соответствующим транспортом (изохронной точкой) вероятность "квакания" == 0. И буфера достаточно на пару мс.

[Atlantis-]

Потому что bulk не гарантирует полосы передачи. В данный момент может всю полосу отдать, а через секунду, рядом, на этом же USB-хабе, другое устройство начало данные гнать - и полоса bulk делится между всеми устройствами на хабе. А ещё хуже если в этот же хаб воткнули устройство с изохронной точкой с рамером кадра близким к максимальному - оно займёт почти всю полосу передачи и все bulk-и будут делить оставшиеся крохи (или несколько устройств с активными изохронными точками в сумме забирающими почти всю полосу).
Как выше уже сказали: только изохронная точка гарантирует полосу передачи. Потому как уже при активации профиля, системный USB-драйвер сразу проверяет "есть ли достаточная полоса для работы изохронной точки?" и если есть - резервирует эту полосу, не давая её занять другим точкам, а если нет - сразу даёт отлуп о невозможности активации профиля.
Ну может ещё interrupt, не знаю - надо смотреть. Всё остальное будет работать от случая к случаю - как повезёт, а значит - нельзя использовать для реал-тайм потоков.

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

Предварительное заполнение буферов, переключение буферов и выборка из них с соотв. частотой. Нужно будет выбрать необходимый размер буфера (чем больше, тем дольше время заполнения, но меньше вероятность "квакания" и прочих артефактов). Но не забывайте, что звук на выходе будет отставать на время заполнения буферов.

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

Простой алгоритм ресэмплинга (по размер очереди буферов) вставкой - выкидыванием выборок есть тут - https://188.134.5.254/browser/hfreceiver/trunk/buffers.c функция buffers_resample

https://188.134.5.254/browser/hfreceiver/tr...buffers.c#L1005

Спасибо, а можете словами объяснить как это работает?

Сообщение отредактировал Atlantis- - Jun 28 2018, 08:08

[jcxz]

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

Ну не знаю как у Вас, а у многих подключены ещё и USB-микрофоны и USB-камеры (для скайпа). А это - потоковые устройства.
Кстати внутри ноутов камеры тоже запросто могут быть на USB cидеть, для унификации.
А ещё есть ТВ-тюнеры. Да ещё куча другой потоковой периферии. Уже не говоря про спец.устройства.

А вот создавая изохронную точку создается потенциальная угроза для других подключенных приборов.

В чём угроза-то? Что пользователя предупредят что ему надо отключить лишние устройства, что бы подключить требуемое? По Вашему лучше молча глючить?
А если сделаете на bulk, то юзеру придётся ваш девайс выключать каждый раз как он захочет флешку воткнуть или USB-HDD. А с изохронной точкой просто скорость чтения/записи этой флешки будет немного ниже.

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

Естественно - заранее заложить требуемый избыток по пропускной полосе. Если скажем поток == 10000 Б/сек, то делается изохронная точка размером (1+10000/1000+1)==12байт, где первый байт указывает кол-во байт в кадре, а последний байт задаёт 10% запас на случай ухода частоты до +10%.
Возможно, что первый байт длины и не нужен, если API в устройстве позволяет принимать неполные изохронные-кадры - кол-во байт определять по принятой длине.

[uriy]

А если сделаете на bulk, то юзеру придётся ваш девайс выключать каждый раз как он захочет флешку воткнуть или USB-HDD

Это еще почему?

[jcxz]

Это еще почему?

Чтоб не "квакало" когда передача данных с флешки будет конкурировать за полосу bulk-а с передачей данных девайса.

[mantech]

С соответствующим транспортом (изохронной точкой) вероятность "квакания" == 0. И буфера достаточно на пару мс.

Я имел ввиду булковый транспорт.

Чтоб не "квакало" когда передача данных с флешки будет конкурировать за полосу bulk-а с передачей данных девайса.

Можно распределить флешку и звук на разные хосты, если уж так. Потому, что если на один посадите, то на моменты энумерации и пр все равно пару раз квакнет.

[Atlantis-]

Ну не знаю как у Вас, а у многих подключены ещё и USB-микрофоны и USB-камеры (для скайпа). А это - потоковые устройства.
Кстати внутри ноутов камеры тоже запросто могут быть на USB cидеть, для унификации.
А ещё есть ТВ-тюнеры. Да ещё куча другой потоковой периферии. Уже не говоря про спец.устройства.

Проблема решается отключением всего вышеназванного. Мой поток данных равен 96 байт в 1 мс (48 кГц, 16 бит, 1 канал), это сравнительно мало.

В чём угроза-то? Что пользователя предупредят что ему надо отключить лишние устройства, что бы подключить требуемое? По Вашему лучше молча глючить? smile3046.gif
А если сделаете на bulk, то юзеру придётся ваш девайс выключать каждый раз как он захочет флешку воткнуть или USB-HDD. А с изохронной точкой просто скорость чтения/записи этой флешки будет немного ниже.

В этом и угроза, что скорость работы другого устройства будет всегда ниже, а вдруг ее не хватит. В то время как потоковая передача - режим временный.
В общем мой вопрос не в этом, а в том как правильно засинхронизироваться.

[uriy]

Чтоб не "квакало" когда передача данных с флешки будет конкурировать за полосу bulk-а с передачей данных девайса.

Тогда через Ethernet по вашему вообще звук передать невозможно? Там же и пакеты теряются и прийти могут не в том порядке что ушли и джиттер не постоянный.
https://ru.wikipedia.org/wiki/Real-time_Transport_Protocol

[Atlantis-]

Почитал про варианты реализации класса Audio, там в асинхронной версии устройство по Interrupt передает на хост какое количество данных хост должен передать, чтобы постоянно держать примерно постоянную заполненность внутреннего буфера, а хост уже на своем уровне решает проблему недостатка/избытка данных.
Все еще непонятно, чем определяется величина буфера устройства.

[Genadi Zawidowsk...]

Спасибо, а можете словами объяснить как это работает?

Работа начинается, когда в выходной очереди (например, блоков DMA для выжачи на кодек/ЦАП) накопилось некоторое стартовое количество блоков.
Их входного потока сэмплов формируются выходные блоки. Если их количество в выходной очереди растет, не чаще чем один раз в 5000 (зависит то возможной рассинхронизации) сэмплов выкидывается или при усыхающей очереди добавляется сэмпл.
Алгоритм добавления в моем примере - среднее арифметическое между соседними.

Сообщение отредактировал Genadi Zawidowski - Jun 28 2018, 14:33

[Rst7]

Спецификация USB.

Если бы я не имел в хозяйстве пару внешних аудиокарт, которые именно Bulk-передачей аудио данные носят, я бы может тоже так категоричен был

Bulk там именно для того, чтобы не потерять данные.

[Genadi Zawidowsk...]

которые именно Bulk-передачей аудио данные носят

Дамп дескрипторов можно? Или хотя бы название. А то у меня есть процессор, в котором только два изохронных ендпоинта, а надо три потока передавать - bulk в нем без ограничений.

Сообщение отредактировал Genadi Zawidowski - Jun 28 2018, 19:34

[Rst7]

Дамп дескрипторов можно? Или хотя бы название.

Название карты? Tascam US-1800. Только чем Вам бы дамп десктрипторов помог? Там не стандартные драйвера используются, а свои собственные.

[jcxz]

В этом и угроза, что скорость работы другого устройства будет всегда ниже, а вдруг ее не хватит. В то время как потоковая передача - режим временный.

Вы совершенно не понимаете принципы организации передач в USB.
Если скорость реалтайм-потока == 10000 б/сек, то размер изохронной точки нужен ==10 байт (+1 байт оверхида на несинхронность частот). Вот эти-то 10-11 байт и зарезервирует системный драйвер, на эту величину и уменьшится скорость работы других устройств. А если бы она не уменьшилась или уменьшилась на меньшую величину, то вы просто не успевали бы свой поток передать. Никаким транспортом и балком в том числе. Как не ухищряйтесь.
И балком вы сможете успевать передавать. только если эти 11 байт будут оставаться от обмена других устройств. Только с балком это будет - как повезёт, а с изохронной точкой - гарантированно. Вот и вся разница.
И скорость будет не "всегда ниже", а только когда активен профиль, в котором прописана данная точка.

PS: Блин! Какое непроходимое дилетантство! Хоть бы почитали чего по теме, прежде чем чего-то делать.... ((

Тогда через Ethernet по вашему вообще звук передать невозможно? Там же и пакеты теряются и прийти могут не в том порядке что ушли и джиттер не постоянный.

Ethernet-то тут каким боком???

Если их количество в выходной очереди растет, не чаще чем один раз в 5000 (зависит то возможной рассинхронизации) сэмплов выкидывается или при усыхающей очереди добавляется сэмпл.

Я делал подстройку частот сложнее и плавнее: у меня при приближении к краям буфера ближе чем на какую-то величину (скажем 15% ёмкости буфера) вводился коэфф. ресэмплинга (нецелый), который линейно уменьшался/увеличивался при приближении к одной из границ буфера о 0% до некоторой величины (скажем 20%) по линейному закону. И на этот коэфф. у меня делался ресэмплинг потока сэмплов.

Bulk там именно для того, чтобы не потерять данные.

Видимо такой же разработчик делал, как в первом посте.
Попробуйте как-нить воткнуть что-нить в тот же хаб с большой изохронной точкой. Да ещё флешку рядом.

Дамп дескрипторов можно? Или хотя бы название. А то у меня есть процессор, в котором только два изохронных ендпоинта, а надо три потока передавать - bulk в нем без ограничений.

Три потока одновременно? И нельзя все данные в один поток сложить?
Можно попробовать interrupt-точку. Для неё нет таких гарантий от системы по полосе, но приоритет передач выше чем у bulk.

[aaarrr]

Видимо такой же разработчик делал, как в первом посте.
Попробуйте как-нить воткнуть что-нить в тот же хаб с большой изохронной точкой. Да ещё флешку рядом.

Напрасно смеетесь - значительное число USB-устройств передает данные в реальном времени bulk-транспортом,
начиная от промышленных камер и заканчивая банальными USB-COM шнурками.

[jcxz]

Напрасно смеетесь - значительное число USB-устройств передает данные в реальном времени bulk-транспортом,
начиная от промышленных камер и заканчивая банальными USB-COM шнурками.

USB-COM - это не поток реального времени, там bulk вполне подходит.

[aaarrr]

USB-COM - это не поток реального времени, там bulk вполне подходит.

А если к тому шнурку подключено устройство, генерирующее изохронный 3Mbit/s поток - тоже не будет реального времени? Избирательно подходите к вопросу

[jcxz]

А если к тому шнурку подключено устройство, генерирующее изохронный 3Mbit/s поток - тоже не будет реального времени? Избирательно подходите к вопросу

Так USB-COM не знает что вы по нему пытаетесь реал-тайм поток передавать. Если-б Вы ему объяснили, то может он и родил бы изохронную точку

[aaarrr]

Так USB-COM не знает что вы по нему пытаетесь реал-тайм поток передавать.

Как это не знает? Никто из инженеров, проектировавших многочисленные адаптеры, не был в курсе возможности передачи непрерывного потока данных через UART?

[jcxz]

Как это не знает? Никто из инженеров, проектировавших многочисленные адаптеры, не был в курсе возможности передачи непрерывного потока данных через UART?

Кто-ж говорит что нельзя передавать? Просто нет гарантии что всё будет успевать доходить.
Изохронная: гарантированная скорость, негарантированная доставка.
Балк и пр.: гарантированная доставка, негарантированная скорость.
Всё это есть в спецификации.

[aaarrr]

Кто-ж говорит что нельзя передавать? Просто нет гарантии что всё будет успевать доходить.

Выходит, забили? Вредительство и спеку не читали.

Вообще, достаточно посмотреть количество USB хост-контроллеров в современных ПК, вспомнить, что на дворе 2018 год, и подавляющее большинство дисков и флешек подключается через персональный USB-SS, а не в соседнюю дырку FS-хаба, чтобы перестать особо переживать за возможный ущерб пропускной способности своего FS bulk-устройства. Я не призываю так делать, но в аппаратуре для профессионального использования вполне допустимо передавать изохронные данные bulk'ом.

[jcxz]

вспомнить, что на дворе 2018 год, и подавляющее большинство дисков и флешек подключается через персональный USB-SS, а не в соседнюю дырку FS-хаба

Не знаю как у Вас, а у меня всё втыкается в один USB-хаб, с хорошим внешним питанием. И дома и на работе. Мне лень лазить за комп и искать где там свободный разъём у него на другом хабе.
А на прошлой работе так вообще у всех коллег на столах USB-хабы стояли с кучами подключенных J-Link-ов, USB-COM-ов, флешек и прочих устройств. Так как руководство следило за порядком на столах сотрудников и требовало системники спускать под стол. А когда нужно по 10 раз в день подключать-отключать разные устройства к USB, то как-то очень неудобно каждый раз под стол лазить и комп оттуда вытаскивать.
Да и когда на обычном комповом хабе висит куча девайсов, то не всякая материнская плата выдаёт честные 5V на VUSB, чаще всего около 4.5V. И тут начинались всякие чудеса с отлаживаемыми девайсами. В конце-концов решили эту проблему кардинально - купили всем хорошие USB-хабы с мощными внешними источниками питания.
Да и некоторые отладчики глючат при длинных проводах по USB (не будем показывать пальцем на SAU510) и желательно хаб иметь вблизи отлаживаемого устройства - на столе.
А ещё на хабе очень удобно наличие кнопок для отключения девайсов без выдирания кабеля. Так что USB-хаб - наше всё в работе.
Так что говорите за себя, а у всех всё очень по-разному.

[aaarrr]

Не понимаю, к чему эта ода USB-хабу. Хотя, раз уж все подключено через один хаб, это автоматически означает наличие кучи свободных хост-контроллеров для подключения "неправильных" устройств, буде возникнет в том нужда

А у меня вот с хабами как-то не сложилось - разве что в мониторе есть, но в него включается 1-2 USB-COM шнурка и телефон на зарядку.
Зато используется несколько удлинителей на HS и SS (под стол никто не любит залезать). Если уж совсем углубиться в оффтоп, то стоит
заметить, что хороший хаб еще поискать надо - в основном продается просто дичайший шлак

[Rst7]

Видимо такой же разработчик делал, как в первом посте.

Да нормальный разработчик. Изохронный режим годится только для просмотра дома фильмов. Ну щелкнет при ошибке - и хрен с ним. Если есть желание не терять данные (например при многоканальном накоплении звука в студии) - то изохронный режим отменяется, остается bulk и ручной контроль за достаточной полосой.

[mantech]

Не понимаю, к чему эта ода USB-хабу. Хотя, раз уж все подключено через один хаб, это автоматически означает наличие кучи свободных хост-контроллеров для подключения "неправильных" устройств, буде возникнет в том нужда

А у меня вот с хабами как-то не сложилось - разве что в мониторе есть, но в него включается 1-2 USB-COM шнурка и телефон на зарядку.
Зато используется несколько удлинителей на HS и SS (под стол никто не любит залезать). Если уж совсем углубиться в оффтоп, то стоит
заметить, что хороший хаб еще поискать надо - в основном продается просто дичайший шлак

В принципе, да, бесили эти хабы, особенно в ранних компах, где 2-4 разъема, а хост 1 или 2 макс, вот и вставишь 2 флешки или винт и скорость сразу резко падает... Потом, когда появилась мать с 6 портами (3 хоста), сразу купил 2 качественных удлинителя (экран+ жилы 24+28авг) всю низкоскоростную шелуху, засунул в порт с хабом, и все полетело на ура, так и до сих пор делаю...

изохронный режим отменяется, остается bulk и ручной контроль за достаточной полосой.

К тому же булк гораздо легче реализовать в самописном драйвере

[jcxz]

Если уж совсем углубиться в оффтоп, то стоит
заметить, что хороший хаб еще поискать надо - в основном продается просто дичайший шлак

Видимо не видели Вы хороших хабов. Вот сейчас у меня на столе: http://www.manhattan-products.com/mondohub
Это вещь - 28 портов с кнопочкой и лампочкой на каждом!

[aaarrr]

Это вещь - 28 портов с кнопочкой и лампочкой на каждом!

Ой. Нет, 28 портов мне точно ни к чему Шести за глаза хватает.

[uriy]

Тоже терпеть не могу эти хабы. И очень редко встречаю чтобы кто-то их использовал. Они все глючат. На столе лежит два Jlink, логический анализатор и USB наушники. Все висит на своем порту на матери. Системник под столом. Нет никаких проблем. Не думаю что в своем устройстве стоит ориентироваться на работу через хаб. Их очень мало у пользователей.

[aaarrr]

Их очень мало у пользователей.

Нет, их полно, причем самых отвратных Поэтому первый пункт при удаленном решении проблем с USB-подключением - "включите устройство непосредственно в порт на задней панели материнской платы".

[jcxz]

Тоже терпеть не могу эти хабы. И очень редко встречаю чтобы кто-то их использовал. Они все глючат.

Так не надо всякий хлам с али таскать. И плеваться потом. Вы ещё флешку на 512 гиг там купите и жалуйтесь потом

[mantech]

Видимо не видели Вы хороших хабов. Вот сейчас у меня на столе: http://www.manhattan-products.com/mondohub
Это вещь - 28 портов с кнопочкой и лампочкой на каждом!

Наверно стоит, как неплохой комп