[Dima1060 0]

Здравствуйте!

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

Добавлю, что нужно использовать Bulk передачи, поэтому прямо взять готовое решение не могу.

Изменено 27 июня, 2018 пользователем Atlantis-

[DmitryM 0]

Здравствуйте!

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

Добавлю, что нужно использовать Bulk передачи, поэтому прямо взять готовое решение не могу.

Isochoronous Endpoint

[Dima1060 0]

Isochoronous Endpoint

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

[uriy 4]

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

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

[jcxz 184]

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

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

[Rst7 5]

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

 

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

[jcxz 184]

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

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

[uriy 4]

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

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

[jcxz 184]

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

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

[Dima1060 0]

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

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

 

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

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

 

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

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

[GenaSPB 11]

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

 

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

 

[jcxz 184]

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

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

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

Ну может ещё interrupt, не знаю - надо смотреть. Всё остальное будет работать от случая к случаю - как повезёт, а значит - нельзя использовать для реал-тайм потоков.

[mantech 33]

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

 

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

[jcxz 184]

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

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

[Dima1060 0]

Потому что 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

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

Изменено 28 июня, 2018 пользователем Atlantis-