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

[Роман М]

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

[bbest]

Тут вот какое дело - я ведь не спрашивал хорошо это или плохо, я спрашивал "что это такое" (по его мнению).

А я не строю из себя великого гуру, в этих вещах разбираюсь скорее всего поверхностно. [Latency] здесь имеется ввиду наверное задержка между выдачей команды на выполнение IO (input output) операцией и ее началом выполнения, может быть задержка в переключениях между задачами/потоками и т.д. вариантов много может быть.

Я как бы, много работаю в эмбеддед области, а там с летенси сталкиваешься очень часто.

С какими именно embedded системами работаешь? Я вообще думаю что все пляски с этими ядрами и настройками линукса и плеера связана с максимально возможным равномерным, ритмичным выводом аудио данных в устройство USB.

[maxssau]

максимально возможным равномерным, ритмичным выводом аудио данных в устройство USB

дык в транспорте вроде обратная синхронизация и временные промежутки довольно жестко ограничены стандартом USB ? Что там оптимизировать?

[bbest]

дык в транспорте вроде обратная синхронизация и временные промежутки довольно жестко ограничены стандартом USB ? Что там оптимизировать?

Да теория она понятна. На форумах я не нашел ответа, поэтому только гадать можно. Как вариант, может влияет буфер в USB устройствах, заполнение которого по максимуму стараются избегать.

[maxssau]

для отладки и оптимизации нужны адекватные замеры, есть ли такое оборудование у дийеров?

[Chaa]

Да теория она понятна. На форумах я не нашел ответа, поэтому только гадать можно. Как вариант, может влияет буфер в USB устройствах, заполнение которого по максимуму стараются избегать.

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

Вы же не будете уменьшать задержки у рутрекера и торрент-клиента, чтобы ваша любимая музыка скачивалась строго равномерно. Или неравномерное скачивание тоже влияет на звук?

[bbest]

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

Я всего лишь предположил. И Аманеро не единственное устройство на котором заметна разница в смене ОС и плееров.

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

для отладки и оптимизации нужны адекватные замеры, есть ли такое оборудование у дийеров?

А что именно замерять вы знаете? Bitferfect будет во всех случаях.

[maxssau]

Bitferfect будет во всех случаях.

тогда я не вижу никаких причин делать пустую работу

[_Summit_]

На форумах я не нашел ответа, поэтому только гадать можно.

Что тут гадать. Не влияет ядро на звук, хоть обсобирайся.

Я всего лишь предположил.

Нет. Ты говорил о впечатляющих результатах.

тогда я не вижу никаких причин делать пустую работу

От скуки и недостатка фантазии. Можно много чем заниматься полезным и приятным.

[Alex]

А я не строю из себя великого гуру, в этих вещах разбираюсь скорее всего поверхностно.

Но ты выдвинул утверждение, так хоть обясни о чем оно.

[Latency] здесь имеется ввиду наверное задержка между выдачей команды на выполнение IO (input output) операцией и ее началом выполнения, может быть задержка в переключениях между задачами/потоками и т.д. вариантов много может быть.

Т.е. ты не знаешь.

С какими именно embedded системами работаешь?

Которые мы разрабатывем, которые работают с внешними сигналами, ввод и вывод, и делают цифровую обработку этих сигналов в реальном времени.
Там, во многих случаях, летенси очень важно.

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

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

Кстати, в линуксах на одноплатниках, лучший вариант - вывод делать не по USB, а по I2S в слейве (полном или по мастерклоку).

[bbest]

Alex,
Понятно. Ну до определенного уровня звука идут по пути наименьшего latency + realtime ядро. Но следующий шаг это когда отпускают ядро в свободное плавание, убирают по максимуму все лишние процессы, остается где то 20-30 процессов, играются с фиксированием частоты ядра и т.д. Сам по себе real-time он же программный, это же то же съедание ресурсов и переключение на другие процессы когда этого не требуется, когда надо вести передачу пакетов.

"Он не бывает "равномерным, т.к. идет пакетами, причем в лучших вариантах - с переменой длиной из-за работы обратной связи." И пусть длина пакетов будет разная, это вовсе не мешает пакеты передавать ритмично. Но опять таки я не настаиваю, что там происходит и что именно влияет на звук глубоко не знаю. Как в принципе и многие, народ просто занимается перебором определенных настроек.

Ну до I2S я еще не дорос.

_Summit_, не бери на себя лишнюю ответственность судить о том чего у меня не достает.

[Alex]

Понятно. Ну до определенного уровня звука идут по пути наименьшего latency

Ты сначала уясни для себя что такое "летенси" а потом говори "понятно".

Сам по себе real-time он же программный,

Не совсем.

И пусть длина пакетов будет разная, это вовсе не мешает пакеты передавать ритмично.

Сами пакеты всегда одинаковой и фиксированной длины и с постоянной частотой (1кгц для фулспида и 8кгц для хайспида), но "полезная нагрузка" в них разная - может быть на весь пакет, может на часть пакета, а может пакет быть и вовсе пустой.

[_Summit_]

убирают по максимуму все лишние процессы

Какие такие процессы? С этого момента поподробнее...

остается где то 20-30 процессов

У процесса много состояний. Это загруженные в память данные, которые процессор будет выполнять (или не будет).

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

А что будет если пакеты будут передаваться не ритмично? Ритм в музыке пропадет?

Но опять таки я не настаиваю, что там происходит и что именно влияет на звук глубоко не знаю. Как в принципе и многие, народ просто занимается перебором определенных настроек.

И у всех впечатляющие результаты? Короч понятно, пальцем в небо. На все руки от скуки.

_Summit_, не бери на себя лишнюю ответственность судить о том чего у меня не достает.

А где я тебя упоминал в данном контексте? Я не в коем случае не осуждаю чужие занятия.
Я вот щас сижу и в носу ковыряю. Рассказать подробности? Каков у меня сегодня впечатляющий результат по козявкам, которые я от туда достал? Не интересно. Я так и знал...

[bbest]

Пока это все слова, вывод то какой, в каком направлении двигаться?

[onefabis]

Кстати, в линуксах на одноплатниках, лучший вариант - вывод делать не по USB, а по I2S в слейве (полном или по мастерклоку).

А в чем преимущество i2s перед USB в данном случае?

[Михаил45]

Пока это все слова, вывод то какой, в каком направлении двигаться?

Ни в каком. Дурью не майся и деньги сбережешь.

[Alex]

А в чем преимущество i2s перед USB в данном случае?

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

[onefabis]

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

Спасибо за развернутый ответ. Теперь ясно.

[Igor_A]

Вы тут всей компанией набросились на bbest, и я должен несколько слов сказать в его защиту. Всё-таки некоторое влияние программной части на воспроизводимый звук в общем случае существует даже при выполнении условий bit-perfect воспроизведения. Автор плеера Audirvana Damien Plisson посвятил этому обстоятельству отдельную статью Beyond bit‐perfect.

Я впервые столкнулся с этой темой в далёком 1999 году, когда сделал первую версию своего плеера, названную MP3 Album Player. Тогда единственным распространённым форматом обмена музыкой был MP3. Я добавил к декодерам и модулям вывода винампа свою оболочку, которая отображала список альбомов и треков и ротировала в своём окне картинки альбома при воспроизведении. Этот плеер использовали даже некоторые изготовители пиратских сборников CD-альбомов. При этом обычная архитектура винампа подразумевала передачу потока в DSP обработку, потом на выход, а я в своём решении замкнул выход декодера и вход модуля вывода, представленных отдельными Dll, напрямую. И вот ещё тогда по факту, без особых размышлений о причинах, меня удивило отличие в звуке оригинального винампа от моего решения. Мысль тогда была, что есть какая-то недокументированная обработка в винампе и она влияет на звук.

Прошло несколько лет, распространились разные форматы, включая lossless, и в середине десятилетия я стал встречать рекомендации по использованию плеера foobar2000 как современного аудиофильского решения. Я скачал фубар и хорошо помню ощущение шока и недоумения, когда, поставив на воспроизведение канадский альбом Высоцкого, я вместо ожидаемого прекрасного звука услышал неестественный звук с присвистываниями на вокале. И никакие настройки не помогали. После этого уже возникло конспирологическое предположение о мировом заговоре врагов звука, которые во все плееры протаскивают скрытую неотключаемую обработку, которая портит звук. Я стал коллекционировать плееры, сравнивать их звук, и через пару лет пришёл к выводу, что везде есть отличия, а больше всего мне нравится звук не плееров, а аудиоредактора SoundForge. Вот тогда появилась мессианская идея, что звук надо спасать и делать честный плеер. И я написал Album Player 2, который просто расширил решение первого плеера на новые форматы, которые распространились за прошедшее десятилетие.

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

[maxssau]

Для анализа джиттера необходим соответствующий измерительный прибор.

Если есть пропуски сэмплов, то это уже не битперфект.

По идее можно увеличить буфер в usb транспорте, что уменьшит возможные пропуски сэмплов, но увеличит задержку. Но опять же джиттер будет зависеть от тактового генератора и расположения генератора относительно изолятора.

Offтопик:

Кстати очень интересный вопрос, разглядывая фото например rme adi2, lynx hilo, lynx aurora с заявленным СШ под 120 дб я не увидел изоляторов. Значит вполне возможно обойтись и без них.

У меня есть скрипт на питоне для генерации wav произвольного содержания, надо попробовать сгенерировать шум в младших битах и посмотреть, что на спектрах.

[Alex]

ещё я узнал о существовании явления под названием "джиттер"

Игорь, "джиттер" - это чисто хардверная характеристика железа в ЦАПе и (не всегда) передачи в него данных. От плеера он никак не зависит.

---------- Сообщение добавлено 10:22 ---------- Предыдущее сообщение было 10:13 ----------

Значит вполне возможно обойтись и без них.

Если подключать измеритель, питающийся от батареек - то можно. Но все-же учти, что все эти измерители КНИ и С/Ш "не видят" ВЧ-помех (СВЧ онитоже не видят, но о СВЧ и изоляторы не помогают).