Ну не знаю как у Вас, а у многих подключены ещё и 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 (зависит то возможной рассинхронизации) сэмплов выкидывается или при усыхающей очереди добавляется сэмпл.
Алгоритм добавления в моем примере - среднее арифметическое между соседними.

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

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

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

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

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

Название карты? 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 поток - тоже не будет реального времени? Избирательно подходите к вопросу