Dima1060 0 27 июня, 2018 Опубликовано 27 июня, 2018 (изменено) · Жалоба Здравствуйте! Нужно передавать речь с микрофона компьютера на устройство по USB, в устройстве STM32F429. Как я понимаю, основная проблема в несовпадении частоты дискретизации на компьютере и в устройстве. Как обычно решается эта проблема? Какие должны быть размеры буфера в устройстве? Добавлю, что нужно использовать Bulk передачи, поэтому прямо взять готовое решение не могу. Изменено 27 июня, 2018 пользователем Atlantis- Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DmitryM 0 27 июня, 2018 Опубликовано 27 июня, 2018 · Жалоба Здравствуйте! Нужно передавать речь с микрофона компьютера на устройство по USB, в устройстве STM32F429. Как я понимаю, основная проблема в несовпадении частоты дискретизации на компьютере и в устройстве. Как обычно решается эта проблема? Какие должны быть размеры буфера в устройстве? Добавлю, что нужно использовать Bulk передачи, поэтому прямо взять готовое решение не могу. Isochoronous Endpoint Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dima1060 0 27 июня, 2018 Опубликовано 27 июня, 2018 · Жалоба Isochoronous Endpoint Я же говорю, у меня Bulk и поменять не могу Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
uriy 4 27 июня, 2018 Опубликовано 27 июня, 2018 · Жалоба Я же говорю, у меня Bulk и поменять не могуТогда причем тут несовпадение частоты дискретизации? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 27 июня, 2018 Опубликовано 27 июня, 2018 · Жалоба Я же говорю, у меня Bulk и поменять не могу Тогда и передавать поток реального времени не можете. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 27 июня, 2018 Опубликовано 27 июня, 2018 · Жалоба Тогда и передавать поток реального времени не можете. Кто ж Вам такое сказал? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 27 июня, 2018 Опубликовано 27 июня, 2018 · Жалоба Кто ж Вам такое сказал? Спецификация USB. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
uriy 4 28 июня, 2018 Опубликовано 28 июня, 2018 · Жалоба Тогда и передавать поток реального времени не можете.RTP можно накинуть Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 28 июня, 2018 Опубликовано 28 июня, 2018 · Жалоба RTP можно накинуть На что накинуть? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dima1060 0 28 июня, 2018 Опубликовано 28 июня, 2018 · Жалоба Тогда причем тут несовпадение частоты дискретизации? При любом типе передачи эту проблему надо как то разруливать, вопрос как. Тогда и передавать поток реального времени не можете. Почему? Поток данных небольшой, теоретически могу позволить себе буфер хоть на две секунды RTP можно накинуть Это что, протокол реального времени? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GenaSPB 11 28 июня, 2018 Опубликовано 28 июня, 2018 · Жалоба Простой алгоритм ресэмплинга (по размер очереди буферов) вставкой - выкидыванием выборок есть тут - 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 28 июня, 2018 Опубликовано 28 июня, 2018 · Жалоба Почему? Поток данных небольшой, теоретически могу позволить себе буфер хоть на две секунды Потому что bulk не гарантирует полосы передачи. В данный момент может всю полосу отдать, а через секунду, рядом, на этом же USB-хабе, другое устройство начало данные гнать - и полоса bulk делится между всеми устройствами на хабе. А ещё хуже если в этот же хаб воткнули устройство с изохронной точкой с рамером кадра близким к максимальному - оно займёт почти всю полосу передачи и все bulk-и будут делить оставшиеся крохи (или несколько устройств с активными изохронными точками в сумме забирающими почти всю полосу). Как выше уже сказали: только изохронная точка гарантирует полосу передачи. Потому как уже при активации профиля, системный USB-драйвер сразу проверяет "есть ли достаточная полоса для работы изохронной точки?" и если есть - резервирует эту полосу, не давая её занять другим точкам, а если нет - сразу даёт отлуп о невозможности активации профиля. Ну может ещё interrupt, не знаю - надо смотреть. Всё остальное будет работать от случая к случаю - как повезёт, а значит - нельзя использовать для реал-тайм потоков. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 34 28 июня, 2018 Опубликовано 28 июня, 2018 · Жалоба При любом типе передачи эту проблему надо как то разруливать, вопрос как. Предварительное заполнение буферов, переключение буферов и выборка из них с соотв. частотой. Нужно будет выбрать необходимый размер буфера (чем больше, тем дольше время заполнения, но меньше вероятность "квакания" и прочих артефактов). Но не забывайте, что звук на выходе будет отставать на время заполнения буферов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 28 июня, 2018 Опубликовано 28 июня, 2018 · Жалоба (чем больше, тем дольше время заполнения, но меньше вероятность "квакания" и прочих артефактов). С соответствующим транспортом (изохронной точкой) вероятность "квакания" == 0. И буфера достаточно на пару мс. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dima1060 0 28 июня, 2018 Опубликовано 28 июня, 2018 (изменено) · Жалоба Потому что 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- Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться