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

Isochoronous Endpoint

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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


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


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

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


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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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


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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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





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

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

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

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

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

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

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