Usb audio device что это
USB-IF опубликовала спецификацию стандарта USB Audio Device Class 3.0
Недавно мы рассказывали о причинах, побуждающих производителей отказываться от использования джека 3.5 мм в мобильных устройствах. Сейчас же группа USB-IF, ответственная за стандартизацию коннектора, выпустила спецификацию USB Audio Device Class 3.0 (ADC 3.0) для тех производителей, которые планируют использовать USB Type-C в качестве интерфейса для передачи звука.
Эта спецификация позволит разработчикам избавиться от 3.5-мм разъема, но при этом поддерживает как цифровую, так и аналоговую передачу звука (через переходники). Также по этой спецификации можно предположить «начинку» будущих USB-C наушников и других аудиоустройств: девайсы будут оснащены многофункциональными процессорными модулями (MPU), способными определять их функционал в конкретный момент времени.
Среди доступных операций синхронизация с источником, ЦАП, шумоподавление, темброблок и управление микрофоном. Кроме того, MPU управляют энергопотреблением устройств: современные USB-C гарнитуры известны своей прожорливостью, новая же спецификация подразумевает, что MPU будет отключать неиспользуемые функции в различные моменты времени, тем самым снижая энергопотребление.
Устройства, построенные согласно этой спецификации, должны поддерживать сжатие USB Audio Type-III и IV, а также будут обратно совместимы с ADC 1.0 и 2.0.
Про аудио и USB-C
Константин Иванов
Переход на USB-C – плохо это или хорошо? Почему он происходит и что несет любителям послушать музыку со своего мобильного устройства?
Вполне возможно, что следующий смартфон, который вы купите, будет поддерживать передачу аудио по USB-C, даже если у него сохранится «обычный» разъем 3.5 мм. А значит, вскоре появится больше наушников с кабелем USB-C, потому что все именно так и работает: добавьте поддержку чего-либо – и компании начнут это производить. Однако использование нового разъема для аудио вызывает массу сомнений и вопросов, как этот опыт будет отличаться от того, что у нас был на протяжении многих лет.
Порт новый, детали те же
Аудиоконтент любого типа может проигрываться на наших смартфонах благодаря слаженной работе ряда особых деталей. Переход от 3.5 мм к USB-C ничего в этом плане не изменит. Однако могут сильно измениться сами детали.
Для того, чтобы превратить файлы на вашем смартфоне в звук, вам потребуются цифроаналоговый преобразователь, усилитель и динамик(и). Динамики за счет вибраций создают волну, которая воздействует на наши барабанные перепонки, а работа их движущихся частей возможна за счет электромагнетизма. Эта волна соответствует тому, что называется аналоговым сигналом, а разновидности этого сигнала представляют собой звуки различного тона. Итак, волновая природа сигнала заставляет вибрировать динамик, эта вибрация порождает волны, которые посылаются на наши барабанные перепонки, а те, в свою очередь, вибрируют в нашей голове, производя звук. Если отбросить биологическую составляющую вопроса, все действительно происходит вот так вот просто. Если вы взглянете на график колебаний аналогового звука и услышите сами звуки, то прекрасно увидите, как эти вещи связаны.
Файлы в вашем смартфоне или файлы, которые передаются через интернет, имеют цифровую природу. Это означает, что это всего лишь кучка единиц и нулей, собранных вместе так, чтобы компьютер мог их прочесть и знал, что с ними дальше делать. Цифровые файлы сами по себе не имеют никакой волновой природы, которая позволила бы динамикам производить звук. Поэтому нам требуется что-то, чтобы конвертировать одно в другое.
Для того, чтобы взять записанное аудио в аналоговом формате, конвертировать его в цифровой формат, например, в файл.mp3, для хранения на компьютере, а затем конвертировать обратно в аналоговый вид для проигрывания, используются сложные алгоритмы. Данные должны попасть в ЦАП для перевода их в волны нужного вида и затем в усилитель, делающий волну достаточно сильной, чтобы она могла работать в наушниках. Для того, чтобы «создавать звук», ученые и инженеры применяют самые разные ухищрения, но описанный процесс необходим для каждого телефона, портативного аудиоплеера и каждого набора динамиков.
Смартфон, например, какой-нибудь LG V30, обладает очень хорошими ЦАП и усилителем, а также аудиоразъемом 3.5 мм. Приложение проигрывает файл, ЦАП преобразовывает его в аналоговый вид, усилитель усиливает сигнал, и все это передается через аудиоразъем 3.5 мм на те наушники, что вы воткнули в устройство. Любой смартфон, имеющий разъем 3.5 мм, работает абсолютно одинаково, неважно, насколько премиальным с точки зрения аудио он является. А вот смартфон, который использует для аудио разъем USB, может работать иначе.
Попробуем объяснить это на примере Bluetooth. Вам не требуется физически подсоединять к чему-то Bluetooth наушники, так что схема организуется иначе, хотя и задействуются в ней все те же элементы. В ваших Bluetooth наушниках есть свои собственные встроенные ЦАП и усилитель. Цифровой файл передается с вашего смартфона, а все преобразования происходят прямо у вас на голове. На первый взгляд это выглядит сложно, но на самом деле – не особо. Происходит точно такой же процесс, разница только в том, где находятся его компоненты. Однако давайте перейдем к USB.
Есть два способа отправить аудио через порт USB, вы уже догадались – цифровой и аналоговый. Аналоговое аудио может быть конвертировано во встроенных ЦАП и усилителе вашего смартфона, а затем отправлено через порт на пассивные наушники или адаптер. Для того, чтобы это произошло, устройство должно поддерживать то, что называется работой в режиме аналогового аудио, и в данном случае наушники или адаптер – это просто проводник сигнала.
Если вы используете активные наушники или адаптер, аудиосигнал, который передается через порт USB, остается в цифровом виде. Это означает, что ЦАП и усилитель находятся внутри наушников или донгла и преобразование происходит там, а не в смартфоне.
Это может вызвать определенные проблемы. Вам нужно удостовериться, что вы используете правильное сочетание гаджетов. Если у вас пассивные наушники или адаптер, ваш смартфон должен поддерживать работу в режиме аналогового аудио, а многие его не поддерживают. И загвоздка в том, что большая часть донглов, адаптеров и наушников никак не маркированы на предмет своей «активности» или «пассивности», нигде не обозначено, как они сделаны.
Pixel 2 имеет встроенный ЦАП в своем чипсете Snapdragon 835 от Qualcomm, однако не поддерживает работу в режиме аналогового аудио. Это значит, что вам потребуются активные наушники или адаптер, такие как донгл, который идет в комплекте. То же самое с HTC U11 и Essential Phone, а единственным смартфоном с поддержкой USB, в котором был заявлен режиме аналогового аудио, был LeEco Le Pro3. Тем не менее, все они должны поддерживать активные наушники или адаптер.
И еще одно: не все аудиоаксессуары с USB работают со всеми смартфонами, поскольку не все производители используют несколько дополнительных проводов USB-C соединения для внедрения дополнительных функций, как сделала HTC в наушниках к U11 для обеспечения активного шумоподавления.
Так что прежде чем купить какие-либо USB-C наушники или адаптер, убедитесь, что они работают с вашим смартфоном
USB-C – лучше или нет?
Ответ – да, но вместе с тем и нет. Реальный звук не улучшается просто от замены порта. Как говорилось выше, вам по-прежнему нужны все те же детали, и производители вольны выбирать среди них как топовые, так и бюджетные. USB-C ничего не меняет, кроме способа подключения.
Но есть и некоторая польза. Стандарт USB Type-C 1.0 был представлен на USB-IF (USB Implementers Forum) в 2014 вместе со спецификациями стандарта USB 3.1. Хотя они и не являются обязательными, у USB-C есть множество фишек, касающихся соединения и подключения. Порт USB-C может поддерживать одновременно следующие функции:
Спецификации USB Type-C не требуют этих функций, но они поддерживаются. Это означает, что с портом USB-C в вашем смартфоне вы можете гораздо больше, чем просто слушать музыку или заряжать его – конечно, в случае, если компания захочет внедрить какой-то из этих дополнительных режимов. Некоторые из них выглядят классно: HDMI или DisplayPort подразумевает, что вы можете подключить свой телефон к аудиосистеме и наслаждаться качественным звуком и изображением на большом экране. И заряжать его, и отправлять данные, и заряжать другой USB-C аксессуар при помощи нужного кабеля – и все это одновременно.
Android наряду с Chrome, Windows, macOS и Linux полностью поддерживают стандарт USB Type-C. И несмотря на то, что звук вовсе не обязательно улучшится, вам могут быть доступны очень полезные функции.
Он уже здесь
Похоже, что ряд смартфонов, например, V-серия от LG, в ближайшее время сохранят разъем 3.5 мм. Это хорошая новость для людей, обладающих аудиоаксессуарами старого стандарта и желающих, чтобы их смартфон выступал в роли классного аудиоплеера. Однако переход на USB-C в аудио уже произошел. И очевидно, что все носимые (и, возможно, самостоятельные) аудиоустройства будут использовать USB-C. А все потому, что это выгодно компаниям, производящим наши любимые гаджеты.
Отказавшись от 3.5 мм, вы больше не обязаны делать свои смартфоны такими же толстыми, как раньше, плюс вы выигрываете несколько квадратных сантиметров на плате для размещения других компонентов. С развитием искусственного интеллекта и машинного обучения на плате требуется место для множества мелких деталей, и теперь это место можно выгадать. Сам по себе разъем под наушники не особо дорог (хотя каждый цент играет роль), но если компания обеспечит устройство режимом аналогового аудио в USB-C подключении, то ей не нужно будет разрабатывать, изготавливать и внедрять какой-либо усилитель сигнала. Это может составить существенную экономию при производстве смартфонов от начала до конца.
Кому-то из нас будет не хватать разъема 3.5 мм. Кто-то привязан к любимым наушникам гораздо больше, чем к плееру или смартфону. Но в конечном итоге выиграют пользователи, если компании предпочтут внедрять полноценный USB-C. А более умное и быстрое подключение – это, безусловно, хорошо.
Выбираем недорогой и качественный USB-аудиоинтерфейс
Оглавление
Вступление
Звуковая карта, она же аудиоинтерфейс — важный элемент любого компьютера или ноутбука, отвечающий за вывод звука. Именно он преобразует сигналы из цифровой формы, в которой аудиоданные хранятся в памяти ПК или на сменных носителях, в аналоговую, необходимую для подачи в усилитель или активную акустику. Он же преобразует звук и в обратную сторону: из аналога в цифру. Эта функция пригодится для записи или использования микрофона.
реклама
Прежде звуковые карты имели исключительно вид платы для установки в слот PCI, в котором они выпускаются и по сей день, но с появлением ноутбуков и планшетов потребовался мобильный аудиоинтерфейс и производители тотчас же на это отреагировали. И сейчас внешнее исполнение уже давно стало стандартом. Когда для подключения проводов не нужно тянуться к задней стенке системника, все необходимые органы управления удобно расположены поблизости, есть усилитель для наушников и можно подключаться хоть к стационарному ПК, хоть к ноутбуку, для многих выбор становится очевиден, поэтому здесь есть из чего выбрать.
Если отбросить Китай, копеечные мультимедийные варианты и аудиоинтерфейсы для геймеров, заточенные больше под работу с объемным звуком, чем на точную передачу нюансов музыки, то остаются или ЦАПы из сегмента HI-Fi, или профессиональные карты. В первой категории можно найти корейский и китайский портатив, немного настольных вариантов и полноразмерные компоненты за большие деньги. Со второй все не так однозначно. С увеличением спроса на доступное профессиональное оборудование для звукозаписи почти все крупные производители ринулись в бюджетный сегмент, расширив ассортимент так называемых полупрофессиональных решений.
Дошло до того, что сегодня можно купить звуковую карту какого-нибудь из известных мировых брендов про-аудио за скромные 3000-5000 рублей. Они, конечно, уступают по качеству профессиональным моделям, но с мультимедийными устройствами и уж тем более с интегрированными точно не сравнятся. Таким образом, на рынке бюджетных решений сложилась интересная ситуация: с одной стороны, за одни и те же деньги (до 15 000) рублей можно приобрести хороший китайский портатив, а с другой — профессиональный аудиоинтерфейс начального уровня с неплохими характеристиками.
Если целью не стоит создание домашней студии звукозаписи, а интересует лишь вывод аудиодорожки на систему звукоусиления, будет достаточно минимальной конфигурации с двумя аналоговыми выходами. Тем, кому необходима возможность прослушивания в наушниках, стоит обратить внимание на наличие соответствующего усилителя и выхода для подключения. Для записи потребуются аналоговые входы и микрофонные предусилители.
USB на регистрах: isochronous endpoint на примере Audio device
Еще более низкий уровень (avr-vusb): habr.com/ru/post/460815
USB на регистрах: STM32L1 / STM32F1
USB на регистрах: bulk endpoint на примере Mass Storage
USB на регистрах: interrupt endpoint на примере HID
Сегодня рассмотрим последний тип конечных точек, изохронный. Он предназначен для передачи данных, критичных к времени доставки, однако не гарантирует ее успешность. Самый классический пример — аудиоустройства: колонки, микрофоны.
Как ни странно, этот тип конечной точки оказался самым мозговыносящим (и это после всего, что я успел повидать с stm’ками!). Тем не менее, сегодня мы сделаем аудиоустройство и заодно чуть-чуть допилим ядро библиотеки USB. Как обычно, исходные коды доступны:
github.com/COKPOWEHEU/usb/tree/main/4.Audio_L1
github.com/COKPOWEHEU/usb/tree/main/4.Audio_F1
Доработка ядра
Допиливать ядро нужно потому, что у STM изохронные точки могут быть только с двойной буферизацией, то есть, грубо говоря, нельзя сделать 0x01 изохронной, а 0x81 управляющей. То есть в дескрипторе USB это прописать, конечно, можно, но внутренности контроллера это не изменит, и реальный адрес точки просто будет отличаться от видимого снаружи. Что, естественно, повысит риск ошибок, поэтому в эту сторону извращаться не будем.
Стоит отметить, что двойная буферизация бывает не только у изохронных точек, но и у bulk, причем включается и работает она иначе. Если изохронные точки включают буферизацию автоматически, просто потому что не умеют по-другому, то для соответствующей настройки bulk приходится использовать специальный бит USB_EP_KIND, который нужно установить вместе с собственно настройкой типа точки.
Сама по себе буферизация означает, что если раньше одной точке соответствовал один буфер на передачу и один на прием, то теперь оба буфера будут работать либо на передачу, либо на прием, причем работать они будут только вместе. Как результат, настройка буферизованной точки сильно отличается от обычной, ведь нужно настроить не один буфер, а два. Поэтому не будем лепить лишние условия в обычную инициализацию, а создадим на ее основе отдельную функцию usb_ep_init_double().
Прием и передача пакетов отличается не так сильно, хотя и отняла гораздо больше времени сначала на попытки понять как же она должна работать по логике ST, потом на подгонку заклинания из интернета чтобы все-таки заработало. Как говорилось раньше, если для обычной точки два буфера независимы и отличаются направлением обмена, то для буферизованной они одинаковы и отличаются только смещением. Так что немножко изменим функции usb_ep_write и usb_ep_read чтобы они принимали не номер точки, а номер смещения. То есть если раньше эти функции предполагали существование восьми сдвоенных точек, то теперь — 16 одинарных. Соответственно, номер новой «полуточки» на запись равен всего лишь номеру обычной, умноженному на два, а для usb_ep_read надо еще добавить единицу (см. распределение буферов в PMA). Собственно, это и делается инлайн-функциями usb_ep_write и usb_ep_read для обычных точек. А вот логику буферизованных рассмотрим чуть подробнее.
Согласно документации, один буфер такой точки доступен для железа, второй для софта. Потом они переключаются и снова не мешают друг другу. Для OUT точки флагом со стороны железа является бит USB_EP_DTOG_RX, который нужно прочитать чтобы понять в какой из буферов только что закончилась запись и откуда соответственно софт может читать. Когда он прочитал свой буфер, нужно дернуть бит USB_EP_DTOG_TX, что собственно переключит буферы. Не уверен, что подразумевалось именно это, но оно, по крайней мере, работает.
Симметричная ситуация должны была быть с IN точками. Но на практике оказалось, что и проверять, и дергать надо USB_EP_DTOG_RX. Почему не TX я так и не понял… Спасибо пользователю kuzulis за ссылку на github.com/dmitrystu/libusb_stm32/edit/master/src/usbd_stm32f103_devfs.c
За счет инлайна функций особого оверхеда не добавилось, не считая инициализации. Но ее можно при желании выкинуть флагами линковщика. А можно и не выкидывать: не так много места занимает, да и вызывается только при инициализации. Это вам не HAL, где функции мало того что тяжелые, но и вызывают друг друга постоянно.
В результате конечные точки научились работать и в буферизованном режиме… если не дышать на них слишком сильно.
Для пользователя разница невелика: вместо usb_ep_init использовать usb_ep_init_double, а вместо usb_ep_write и usb_ep_read — соответственно usb_ep_write_double и usb_ep_read_double.
Устройство AudioDevice
А вот теперь, когда с техническими граблями разобрались, перейдем к самому интересному — настройке аудиоустройства.
Согласно стандарту USB аудиоустройство представляет собой набор сущностей (entity), соединенных друг с другом в некую топологию, по которой и проходит аудиосигнал. Каждая сущность имеет свой уникальный номер (bTerminalID, он же UnitID), по которому к ней могут подключаться другие сущности или конечные точки, по нему же обращается хост, если хочет изменить какие-то параметры. И он же считается единственным выходом данной сущности. А вот входов может вообще не быть (если это входной терминал), а может быть и больше одного (bSourceID). Собственно записью в массив bSourceID номеров сущностей, от которых текущая получает аудиосигнал, мы и описываем всю топологию, которая в результате может получиться весьма резвесистой. Для примера приведу топологию покупной USB-звуковой карты (цифрами показаны bTerminalID / UnitID):
Мы же будем делать нечто более простое (заготовку брал отсюда):
Здесь видно две независимых ветки распространения сигнала: либо от USB через «фичу» к «динамику», либо из «микрофона» через другую «фичу» к USB. Микрофон и динамик не просто так взяты в кавычки: на моей отладочной плате их нет, поэтому вместо собственно звука будем пользоваться кнопками и светодиодами. Впрочем, ничего нового. «Фичи» в моем случае ничего не делают и добавлены скорее для красоты.
Сразу же стоит уточнить, что сигнал в данной модели считается составленным из одного или более логических каналов. То есть если, например, я поменяю монофонический динамик на стереофонический, сама топология останется неизменной, изменится только формат сигнала.
Глубоко в различия сортов «фич» и прочих сущностей я не копал, но пересказать кусок документации не побрезгую.
1. Входной терминал (Input Terminal)
Как следует из названия, именно через него в аудиоустройство попадает звуковой сигнал. Это может быть USB, может быть микрофон обыкновенный, микрофон гарнитурный, даже микрофонный массив.
2. Выходной терминал (Output Terminal)
Тоже вполне очевидно — то, через что звук покидает наше устройство. Это может быть все тот же USB, может быть динамик, гарнитура, динамик в мониторе, динамики различных частот и куча других устройств.
3. Микшер (Mixer Unit)
Берет несколько входных сигналов, усиливает каждый на заданную величину и складывает то, что получилось, в выходной канал. При желании можно задать усиление в ноль раз, что сведет его к следующей сущности.
4. Селектор (Selector Unit)
Берет несколько входных сигналов и перенаправляет один из них на выход.
5. Фильтр (Feature Unit)
Берет единственный входной сигнал, меняет параметры звука (громкость, тембр и т.п.) и выдает на выход. Естественно, все эти параметры одинаковым способом прикладываются ко всему сигналу, без взаимодействия логических каналов внутри него
6. Processing Unit
А вот эта штука уже позволяет проводить манипуляции над отдельными логическими каналами внутри каждого входного. Более того, позволяет сделать количество логических каналов в выходном не равным количеству во входных.
7. Extension Unit
Весь набор нестандартных сущностей, чтобы больной фантазии производителей оборудования было раздолье. Соответственно, и поведение, и настройки будут зависеть от этой самой фантазии.
Некоторые сущности обладают параметрами вроде коэффициента усиления или номера канала, на которые хост может повлиять при помощи setFeature / getFeature запросов по номеру сущности. Но тут, если честно, я не слишком понимаю как это вообще проверить. Наверное, нужен какой-то спецсофт, которого у меня нет. Ну да и ладно, все равно я в это полез только чтобы все типы точек проверить… на свою голову…
Грабли в дескрипторе
В отличие от предыдущих USB-устройств, здесь дескриптор сложный, многоуровневый и склонный пугать виндоусы до BSOD’а. Как мы видели выше, топология у аутиоустройства может быть весьма сложной и развесистой. Под ее описание выделяется целый интерфейс. Очевидно, endpoint’ов он содержать не будет, зато будет содержать список дескрипторов сущностей и описаний к чему подключены их входы. Тут особо описывать смысла не вижу, проще посмотреть в коде и документации. Отмечу только главные грабли: здесь описывается какие интерфейсы с соответствующими конечными точками относятся именно к данному устройству. Скажем, если вы захотите изменить мою конфигурацию и убрать оттуда динамик, придется не просто удалить половину сущностей (слава макросам, хотя бы с подсчетом длины дескриптора проблемы не будет), но и уменьшить поле bInCollection до 1, после чего из следующего за ним массива bInterfaceNr убрать номер лишнего интерфейса.
Дальше находятся интерфейсы, отвечающие за обмен данными. В моем случае 1-й интерфейс отвечает за микрофон, а 2-й за динамик. Здесь стоит обратить внимание в первую очередь на два варианта каждого из этих интерфейсов. Один с bAlternateSetting равным 0, второй с 1. Они отличаются наличием конечной точки. То есть если наше устройство в данный момент не используется, хост просто переключается на тот альтернативный интерфейс, который конечной точкой не оборудован, и уже не тратит на нее пропускную способность шины.
Вторая особенность интерфейсов данных — это формат аудиосигнала. В соответствующем дескрипторе задается тип кодирования, количество каналов, разрешение и частота дискретизации (которая задается 24-битным числом). Вариантов кодирования предусмотрено довольно много, но мы будем использовать самый простой — PCM. По сути это просто последовательность значений мгновенной величины сигнала без какого-либо кодирования, причем величина считается целым числом со знаком. Разрешение сигнала задается в двух местах (зачем — непонятно): в поле bSubFrameSize указывается количество байтов, а в bBitResolution — количество битов. Вероятно, можно указать, что диапазон нашей звуковой карты не доходит до полного диапазона типа данных, скажем, int16_t и составляет всего 10 бит.
Ну и наконец дескриптор собственно конечной точки. Он тоже немного отличается от обычных, поскольку предусматривает во-первых несколько вариантов синхронизации, а во-вторых, номер сущности, с которой эта точка ассоциирована (bTerminalLink). Варианты синхронизации прописываются старшими битами прямо в тип конечной точки (именно поэтому изохронная точка вынесена в ветку default в функции инициализации), но их подробностями я не занимался, поэтому ничего интересного рассказать не смогу. Вместо синхронизации мы воспользуемся обычным таймером контроллера, который будет генерировать прерывания с примерно нужной частотой.
Ах да, чуть не забыл упомянуть очередную пачку BSOD’ов при тестировании неправильных дескрипторов. Еще раз напоминаю: количество интерфейсов данных должно соответствовать числу bInCollection, а их номера — следующему за ним массиву!
Логика работы устройства
А вот с тестированием возникла небольшая проблема: я не нашел простого способа перенаправить сигнал с микрофона на stdin какой-нибудь программы. Вроде бы раньше это делалось просто чтением /dev/dsp, но сейчас что-то поломалось. Впрочем, ничего критичного, ведь есть всякие библиотеки взаимодействия с мультимедией — SDL, SFLM и другие. Собственно на SFML я и написал простенькую утилиту для чтения с микрофона и, если надо, визуализации сигнала.
Особое внимание уделю ограничениям нашего аудиоустройства: насколько я понял, изохронный запрос IN отправляется один раз в миллисекунду (а вот OUT’ов может быть много), что ограничивает частоту дискретизации. Допустим, размер конечной точки у нас 64 байта (учитывая буферизацию, в памяти она занимает 128 байт, но хост об этом не знает), разрешение 16 бит, то есть за раз можно отправить 32 отсчета. Учитывая интервал в 1 мс получаем теоретический предел 32 кГц для одного канала. Самый простой способ это обойти — увеличить размер конечной точки. Но тут надо помнить, что размер общего буфера PMA у нас всего 512 байт. Минус таблица распределения точек, минус ep0, получаем максимум 440 байт, то есть 220 байт на единственную точку с учетом буферизации. И это теоретический предел.
Но то, что хост может за один фрейм послать несколько OUT запросов наводит на мысли, что и устройство тоже так может. Осталось понять как. Возможно, это решается грамотной настройкой синхронизации. Но для меня этот вопрос интереса уже не представляет: изохронные точки работают, буферизованные точки работают, аудиоустройство работает — задача выполнена.