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

[Atlantis-]

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

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

[uriy]

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

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

[Atlantis-]

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

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

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

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

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

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

[jcxz]

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

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

[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 в устройстве позволяет принимать неполные изохронные-кадры - кол-во байт определять по принятой длине.