Высококачественный звук в Linux и в Linuх-подобных ОС

[Роман М]

Возможно баян, но хочется узнать на счет возможность реализации высококачественного цифрового источника на базе Linux и Linux-подобных OC, например Ubuntu, Android. В первую очередь интересуют следующие вопросы:
1) Поддержка USB Audio девайсов
2) Вывод аудиопотока с бит-перфектом
3) Поддержка losless и hi-res контента
4) Подходящие софтовые плейеры
5) Сравнение по качеству звука с виндой
У кого есть опыт просьба поделиться.

[Alex]

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

Зависит от способа синхронизации, кои бывают асинхронные, синхронные и адапривные. Но разницы нет. (в смысле - разсинхронизации буферов нет )

[_Summit_]

Проигрываетль в ОС отдает куски памяти по запросу.

Кому отдает? Кто запрашивает?

[Yurgen]

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

Хорошо, но откуда аудиоплейер или медиаплейер при воспроизведении кино к примеру знает что аудио ЦАП закончил проигрывание очередной порции семплов? Он проигрывает непрерывно со своей частотой и ему пофиг что там происходит дальше. А дальше драйвер должен буферизировать поток и отдавать его по запросу, это для случая асинхронного проигрывания. Либо тоже самое должен делать приемник USB на стороне ЦАПа. А теперь вопрос, насколько длинный буфер FIFO, заметна ли пауза при начале проигрвания или отставание звука от изображения? Если он достоточно мал чтобы такого не ппоисходило, тогда второй вопрос, что происходит при переполнении буфера на длинных композициях или при просмотре кино?

[l3VGV]

Я там дополнил ответ.

Поясню на примере как оно работает.

Я как погромист говорю, "ось, будем играть Звук", если у оси всё хорошо, она скажет ок. Далее я говорю ей какой формат: сколько каналов, сколько бит в семлпе, сколько семплов в секунду, длинну буфера тоже нужно указать(гдето нужно самостоятельно выделить кусок памяти, где как). далее я указываю ту функцию которую ось должна взывать когда ей понадобится перезаполнить буфер. Для начала собственно процесса я говорю - старт, теперь ос сама будет взывать эту функцию в моём процессе. Моя задача реализовать её так, чтобы она отработала быстрее чем будет вызвана ещё раз, все вменяемые люди делают просто - кусок данных готовится заранее, и как только ОС его просит, то сразу он выдается туда, а потом сразуже начинается подготовка следующего куска.

Внутри оси присходит примерно тоже самое, даже если карта не юсб а пси. Драйвер говорит - ОС давай данные, ос быстро выдает запасенный буфер и выдает наверх запрос на следующий. Внутри приемника звуковой карты, там опять ФИФО, который работает обратно также только в самом конце данные начинают вываливаться в I2S последовательно, но и даже внутри передатчика всегда есть ещё один двойной буфер, один выходит в данный момент наружу, а второй перезаполняется. Момент перключения вообще не заметен в такой архитектуре. Применяется повсеместно, что в звуке что в графике, да и где угодно.

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

Ничего нигде не теряется и не придумывается. Даже если ктото подвинул нас на USB, например bulk или control, то у нас буфер, главное успеть за его длину.

Единственная неприятная ситуация - получили кусок данных у которого CRC не совпадает. Но и ситуация такая в реальности как выигрыш в лотерею - крайне редка.



Как синхронизуют звук и картинку кино плееры я не знаю, не ковырял. Я строго по звуку и форматам файлов. Если нужна статичная задержка тут всё просто, но понятно что vsync монитора и клоки звука будут иметь рассинхрон. Не большой, но думаю на размерах фильма в конце максимум будет заметно ну на сотню другую мс(просто наплевать). Картинку в отличии от звука можно паузить, особенно если мы 29 кадров показываем на 60Гц панель. Но думаю никто на это не заморачивается.

[Yurgen]

Я как погромист говорю, "ось, будем играть Звук", если у оси всё хорошо, она скажет ок

Т.е. все абсолютно аудиплееры выводят звук в винду через функцию обратного вызова? А медиаплеер проигрывание видео подстраивает под аудио?

[l3VGV]

Т.е. все абсолютно аудиплееры выводят звук в винду через функцию обратного вызова

Возможно ли ответить на подобный вопрос?

А медиаплеер проигрывание видео подстраивает под аудио?

Вывод картинки на экран он также идёт не просто так. Можно подстраивать, а можно и забить. Как сделано в реальности можно глянуть в кишках какогонить популярного плеера, например mpc-hc

[Alex]

Хорошо, но откуда аудиоплейер или медиаплейер при воспроизведении кино к примеру знает что аудио ЦАП закончил проигрывание очередной порции семплов?

А как Эксплорер/ФАР/Тотал/вотевер, копируют файл на медленный накопитель, не задумывался?

[Yurgen]

Хорошо допустим винда опрашивает аудиоплейер через функцию обратного вызова. Нажимаем play, из динамиков компа идет звук через аудиокарту. Через USB поток идет отдельно допустим блоками с подтверждением готовности со стороны ЦАПа. Теперь опять все тот же вопрос откуда винда берет mclk при проигрывании аудифайла? Вероятно с аудиокарты и подстройка через функцию обратного вызова идет по mclk аудиокарты. Тогда опять возникает вопрос синхронизации частоты mclk аудиокарты и ЦАПа.

[l3VGV]

А как Эксплорер/ФАР/Тотал/вотевер, копируют файл на медленный накопитель, не задумывался?

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

Пока учился в ВУЗе то мы с сокурсником посвятили этому вопросу некоторое количество времени. В часности почему винда копирует файлы медленнее чем фар или виндовс командер. Оказалось там на всё есть свои веские причины. В том плане что фар и командер не правы, а эксплорер прав. Хотя все они пользуются для работы методами ОС.


Для не специалистов поясню, что даже если я делаю WriteFile который открыт на медленном носителе, то далеко не факт что моя программа сразу залипнет, для начала всё попадает в буфера. И будет туда падать пока либо они не кончатся, и тогда следующий вызов WriteFile будет ожидать пока они очистятся, либо пока я не вызову FlushFileBuffers, и опятьже буду ждать пока буфера очистятся. Т.е. выполнение всего потока остановится, и будет ждать, а чо там у файлов!

Можно и для звука так АПИ реализовать(причем наверняка оно есть для какойнить совместимости), однако к чему подобный устаревший подход? Блокировки вот эти лишние... Только асинхрон, только простота, гибкость, надежность и удобство!

Пока писал, вспомнил про прелестный PlaySound, ах. С тебя всё начиналось... PlaySound("recycle.wav"), прелестный простой блокирующий или нет метод(если не изменяет склероз там можно спросить подождать пока закончит играть или работать дальше паралельно) , но внутри оно всёравно развалится на вышеописанную схему работы.

[Meta|_]

А на матери разве нет преобразователей питания? И кондерами она увешена. Чет я сомневаюсь, что ток нагрузки проца идет по питающим кабелям в БП.

Представь себе, процессор в простое. И тут мы резко начинаем декодировать порцию музыки из FLAC*а. Начинает сильнее молотить DC-DC*шник процессора, за ним "разгоняется" и основной БП. Через миллисекунду декодирование заканчивается. Если такое повторть 10 раз в секунду, то модуляция помех от БП будет вполне наблюдаема приборами.

Вообще, это все приборами прекрасно видно.

В том-то и дело, что помехи от БП компа, пролезающие "через эфир" зачастую прекрасно видно приборами на расстоянии нескольких метров. Иногда просто на высокоомный щуп осциллографа наводится видимая помеха.

через множество, как минимум, дабл буферов

ИМХО, там обычно кольцевые буферы. В стандарта ASIO точно были прописаны именно кольцевые.
Все наверное слышали как зацыкливаются последние несколько сотен миллисекунд когда комп зависает

Картинку в отличии от звука можно паузить, особенно если мы 29 кадров показываем на 60Гц панель. Но думаю никто на это не заморачивается.

Ещё как заморачиваются! Иногда даже предпочитают на лету ресемплить звук, чтобы картинка была плавной (кадры фильма точно попадали в развёртку монитора).

Теперь опять все тот же вопрос откуда винда берет mclk при проигрывании аудифайла?

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

[l3VGV]

Теперь опять все тот же вопрос откуда винда берет mclk при проигрывании аудифайла?

Винде не нужен mclk. Винда, или иная ОС, оперирует таймерами и кусками памяти. Как только кусок памяти выдан наружу, она обрабатывает новый кусок. Если успевает сделать новый кусок пока не кончился старый, то пользователь щаслив.

---------- Сообщение добавлено 18:09 ---------- Предыдущее сообщение было 18:07 ----------

Все наверное слышали как зацыкливаются последние несколько сотен миллисекунд когда комп зависает

Как там в асио я сходу не вспомню, но кольцевым ему для зацикливания быть не обязательно. Достаточно переключаться между двумя(или более) не перезаполненными новыми данными буферами.

Но это уже мелкие детали, на большую картину это не влияет.

---------- Сообщение добавлено 18:12 ---------- Предыдущее сообщение было 18:09 ----------

Если мастерклок в ЦАПе на ходу разогнать (при условии что звуковуха синхронизируется именно от ЦАП) то Винде совместно с плеером придётся быстрее напихивать данные в буфер, как следствие "секунды" в плеере начнут щёлкать быстрее.

Давно мечтаю попробовать, но всё лень. Имею мнение что в таком сценарии дрова винды выдадут синий экран. Гдето читал про что виндовский изохрон не любит когда его мучают сложностями бытия.

[Yurgen]

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

Вопрос в том к чему привязан вызов callback из API винды, если он привязан к mclk аудиокарты будет рассинхронизация с ЦАПом. Или его синхронизация переключается на USB когда подключается внешнее аудиоустройство, а встроенная аудиокарта при этом отключается?

[l3VGV]

А для каждого аудио устройства своё тактирование. Не связанное с другими.

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

[Meta|_]

Но это уже мелкие детали, на большую картину это не влияет.

Однозначно. Просто с кольцевыми проще объяснять, т. к. это по сути FIFO: с одного конца байты запихивают, с другого - вытаскивают. Всё понятно на пальцах

Давно мечтаю попробовать, но всё лень. Имею мнение что в таком сценарии дрова винды выдадут синий экран. Гдето читал про что виндовский изохрон не любит когда его мучают сложностями бытия.

Я пробовал, но это было давно. Я даже не уверен, была у меня карта PCI или ISA ОС - либо NT4, либо XP.

Вопрос в том к чему привязан вызов callback из API винды, если он привязан к mclk аудиокарты будет рассинхронизация с ЦАПом. Или его синхронизация переключается на USB когда подключается внешнее аудиоустройство, а встроенная аудиокарта при этом отключается?

Переключение с одного устройства на другое - это отдельная песня. И на лету это поддерживают далеко не все программные интерфейсы. Всякие WASAPI и ASIO - не поддерживают, т. к. привязываются к конкретному устройству вывода звука. DirectSound - может и поддерживает, я не пробовал.

[Yurgen]

Допустим с аудиплейером именно так, внутреняя звуковуха компа отключается, как тогда происходит проигрывание видео, ему ведь нужен свой mclk?

[Meta|_]

Допустим с аудиплейером именно так, внутреняя звуковуха компа отключается

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

[l3VGV]

Вопрос совершенно не понятен.

Я буду говорить о стандартном виндовом апи, которое раньше называлось win32, в directsound и прочих ASIO и WSAPI могут быть другие нюансы, но основная картина таже.

С точки зрения ОС ей всёравно кто использует её функции, аудио или видео плеер.

С точки зрения програмиста, запрос на вывод семплов можно инициализировать на любое устройство, для того чтобы определить что есть в данном компе у ОС предусмотрены спец функции перечисления интерфейсов.

У интерфейса нет клоков. В ОС, нет. Они есть только в самом конце, где уже стоит мелкосхема преобразователя. Откуда там этот клок - ОС всёравно. ОС клоками не управляет. Сами интерфейсы не имеют общих синхронизаций. Т.е. у всех разные клоки, встроенная карта имеет один ген на 25МГц и из него делает все нужные на любую сетку частот. А ATDAC8 на юсб имеет свои выделенные 2 генератора которыми сам управляет.

Если я запрашиваю вывод на какойто интефрейс, ОС спросит его готов ли он к работе. Чо там будет в этот момент - включение генераторов, запуск PLL на захват и сужение, или феи будут дергать маятник - ОС всёравно. Главное чтобы в конце интерфейс начал принмать данные и общатсья с ОС в установленном порядке об их получении.

Если я попрошу одновременный вывод в 2 интерфейса, то ОС будет делать запрос данных для каждого из них отдельно, в зависимости от их личного состояния. Т.е. они не будут синхронизированы некоторым общим mclk.


Вопрос синхронизации нескольких интерфейсов одним общим клоком это отдельная весёлая и забористая задача.

[Meta|_]

как тогда происходит проигрывание видео, ему ведь нужен свой mclk?

С видео всё сложно. Возможны три варианта.
1. Звук выводим с той скоростью, с которой звуковуха вытаскивает из буфера данные, кадры видео - выдаём асинхронно. Тогда либо некоторые кадры видео будут задержаны до следующего обновления монитора, либо будет "рваная" картинка. Сейчас ещё появились мониторы, умеющие обновляться асинхронно, но это пока экзотика.
2. Звук выводим с той скоростью, с которой звуковуха вытаскивает из буфера данные, кадры видео - строго в соответствии с развёрткой монитора. Тогда на длинном фильме звук и изображение могут разойтись.
3. Кадры видео выводим строго в соответствии с развёрткой монитора, а звук чуть ускоряем/замедляем, чтобы он не "убегал". То есть асинхронно ресемплим на лету.

[Alex]

Давно мечтаю попробовать, но всё лень. Имею мнение что в таком сценарии дрова винды выдадут синий экран.

Не выдадут. во всяком случае, если файл в 44.1*х а mclk = 48х никаких синих экранов не наблюдается. Только файл воспроизводится быстрее (и тональность естественно выше).
У меня на USB-интерфейсе xV стоит перемычка, определяющая полярность переключения сетки частот. Если ее поставить не правильно, то и будет то что описано выше. Соответственно. при воспроизведении файла в 48*х, mclk будет в 44.1х и файл будет медленее.

Для проверки правильности переключения клоков я просто воспроизвожу с генератора 1кгц и смотрю частотомером (осциллографом разумется), чтобы на выходе ЦАПа было тоже 1кГц а не 1.088кГц.

Аналогично, при разработке/отладке АЦП, с I2S в USB-приемнике в слейве, у меня много раз было что в винде в софте (в СпектраПлюсе, например) стоит 48, а реально АЦП шлет в приемник 96. Сигнал естественно не правильный, но никаких синих экранов.
Так что, неправильный клок винда вполне терпит.

[Yurgen]

Ничего не отключается. Можно одновременно через одно звуковое устройство воспроизводить один файл, а через другое - другим плеером другой файл. Или тот же. У обоих устройств независимые мастерклоки, и воспроизведение будет идти с чуть-чуть разной скоростью.

Ок, настроили вывод через встроенную звуковую карту и одновременно через USB ЦАП. Аудиплейер один, callback одна. Как ось будет дергать callback, если скорость считывания у аудиоустройств разная?