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

[Роман М]

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

[anli]

Offтопик:

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

Я репочу (и в больших количествах) баги в случаях, если программа является действительно часто мною используемой (или же проблема - явный show stopper). DeadBeef пока к таким не относится

[Роман М]

Собственно почему я завел эту тему. Подбираю подходящую платформу для домашнего медиаплейера. Основные требования - Full HD видео, HR losless аудио, вывод аудиопотока на USB, интернет. На счет wintel-платформ все предельно ясно, наиболее подходящая платформа - AMD Fusion. Тут или неттоп, или "самопиленная" машина на базе mini-ITX материнки. Все бы хорошо, но неттопов на Fusion c пассивным охлаждением нет, на базе mini-ITX при желании конечно можно сделать за счет доработки штатных СО, но все как-то не бюджетно получается и громоздко. Между тем появляются довольно интересные, компактные, низкопотребляемые, безшумные и совсем недорогие ARM-платформы на базе Linux-подобных ОС. По идее идеальный вариант, но с поддержкой USB-audio и HR все как-то не очень понятно в них.

[nazar]

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

раньше я тоже неприемлил такую регулировку, но на самом деле тут проблема в цапе (а не в методе), если он отрабатывает прекрасно низкоуровневую инфу то даже при физическом 16-18битнике регулировка на 30-40дб не портит звук абсолютно, не говоря уже про мой последний 24розрядник

[anli]

30-40дб

Не могу проверить, так как Ку усилителя небольшой, но мне кажется, что несколько преувеличено. 40db - это уж очень много. Ты как тестировал?

[nazar]

Реально максимально достижымий ДД в хорошой студии 100...105дб, но никто необработанную такую фонограму не выпутит (ну практически никто, знаю кто так делает) а обязательно подожмет, и вот большинство зиписей очень хорошо если 60дб ДД имеют, много есть с 40кой, крайне редко 80 в основном классика итд, про то какой ДД можно получить у себя дома это ваще отдельная песня).
Ну и 16бит филипс принял в те года как видиш не с бухты барахты

---------- Добавлено в 14:00 ---------- Предыдущее сообщение в 13:59 ----------

Вот если у тя цапик уже 100дб ДД прекрасно будет в реальности выдавать то и софтом можно очень успешно рулить

---------- Добавлено в 14:02 ---------- Предыдущее сообщение в 14:00 ----------

Правда вопрос еще как регулировка сделана, даже в таком часто лажают не по детски)

[anli]

Вот если у тя цапик уже 100дб ДД

Как, кажется, писал выше, и -110db при Ку около пяти прекрасно слышно.

Правда вопрос еще как регулировка сделана, даже в таком часто лажают не по детски

Именно об этом предложенный мой тест.

[nazar]

Как, кажется, писал выше, и -110db при Ку около пяти прекрасно слышно.

слышно это немного не то)

[anli]

слышно это немного не то)

Я имел в виду что и слышно, и регулируется. То есть, скажем, 16-битный сигнал с уровнем -80db ослабляешь на 30 db. И тон слышно, и модулированный тон. Или что ты имеешь в виду под "то"?

[nazar]

а может он на 32дб ослабляется а не на 30, и при том еще появляется что то лишнее в сигнале

[anli]

а может он на 32дб ослабляется а не на 30

Нет, ослабляет на 30db - я по этому поводу тоже патч написал (1% равен строго 0.5 db), правда он ещё не принят. Ну и у RME это можно проконтролировать.

и при том еще появляется что то лишнее в сигнале

У меня нет приборов такой никакой сигнал исследовать. Но ушами на таком уровне лишнего не слышно, как нетрудно догадаться - там и сам сигнал-то никакой, не говоря уже про "лишнее"

[antecom]

Попалась страничка по теме, может чем то поможет с выбором.

Offтопик:

Самый лучший вариант, это терминальное управление из КПК, смартфонов, мобильтников и т.п. штук. Это или клиент mstsc (им я пользуюсь из windows mobile), или скоро гугл сделает свою темку

Согласен. Более полугода пользуюсь смартфоном с андроид и вот этой клиентской программой. Достаточно удобно.
Серверная часть для фубара - foo_touchremote

[aleyer]

Собственно почему я завел эту тему. Подбираю подходящую платформу для домашнего медиаплейера. Основные требования - Full HD видео, HR losless аудио, вывод аудиопотока на USB, интернет. На счет wintel-платформ все предельно ясно, наиболее подходящая платформа - AMD Fusion. Тут или неттоп, или "самопиленная" машина на базе mini-ITX материнки. Все бы хорошо, но неттопов на Fusion c пассивным охлаждением нет, на базе mini-ITX при желании конечно можно сделать за счет доработки штатных СО, но все как-то не бюджетно получается и громоздко. Между тем появляются довольно интересные, компактные, низкопотребляемые, безшумные и совсем недорогие ARM-платформы на базе Linux-подобных ОС. По идее идеальный вариант, но с поддержкой USB-audio и HR все как-то не очень понятно в них.

Меня тоже заинтересовала эта тема...
Не вижу плат за адекватную цену с наличием SATA-контроллера. Точнее видел буквально одну плату в продаже с совершенно неинтересным процессором.
Не так давно решил сравнить производительность ARM и x86 процессоров (ну, не с i5, конечно), запустил на воспроизведение в deadbeef*е один и тот же файл в APE на компе с AMD Duron на 800МГц и на смарте с процессором Marvell PXA920 на 806МГц (архитектура старая ARM9). Грубо говоря вышел паритет, загрузка процессора до 30% при воспроизведении 44.1кГц 16бит. Воспроизведение FLAC*а менее требовательно, понятное дело. Мой комп тянет воспроизведение FLAC*а в 96кГц 24 бита, значит и ARM-плата на более современной архитектуре ARM, чем ARM9 (хоть ARM11, хоть последняя ARM15, хоть Cortex) с такой же или большей частотой должна с этим справляться.

[Nikkov]

С армами есть большая засада: самостоятельно под них плату не сделаешь (вернее сделать можно, но очень затратно), а готовые плееры/PDA/отладочные комплекты не заточены под качественный вывод звука., Ну и часто на процессоры, что используются в массовых девайсах, не найти даташитов.

[nazar]

Нет, ослабляет на 30db

смотрел на выходе цапа?)

[anli]

Offтопик:

смотрел на выходе цапа?)

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

[ZugDuk]

Offтопик:

Твой плеер, наверное, мой тест не проходит, вот ты и прикалываешься Ну и вообще ещё никто не отчитался о проделанной работе, хоть той работы на несколько минут

У меня ЦАП 16ти битный (вспомнилось тут )

[nazar]

anli, я вообщето серезно, ты меня просто не понял

[Shim]

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

anli, под линуксом не надо ухи в динамики совать, это совершенно лишнее, (повторяемость опыта паршивая) проверить bit-to-bit (и качество софтового регулятор) намного проще: в .asoundrc прописать алиас для alsa-plugin*а pcm.writefile. И указать это алиас для вывода потока в плеере (если плеер тупой, и не умеет работать с алиасами, в том же .asoundrc переопределить pcm.default). И всё. Запустил кусок трека, и рассматривай потом оригинальный и полученный WAV файл. Причем если плеер урезал битность до 16-ти, то и файл будет в формате 16 бит, и частота дискретизации файла покажет есть ресемплер или нет. Уровни оригинального и результирующего файла сравнить чуть труднее: начало трека в результирующем файле может идти не с самого начала (от плеера, и настройки буфферизации зависит), может быть произвольное кол-во ноликов в начале. Поэтому лучше модифицировать исходный трек перебив начальные сэмплы (на что-нибудь типа FF FF 00 FF 00 FF 00 FF), чтоб глазами найти начало в итоговом файле и вырезать лишние нулевые сэмплы, даже если есть софтовая регулирвка и дизеринг. Ну а потом не мне вам рассказывать как вычесть один звуковой файл из другого.

Offтопик:
Цитата Сообщение от ZugDuk Посмотреть сообщение
Проблема описанная тобой в первых 4ех строчках не может существовать для фубара

Так ты в натуре проверил? Это быстрее, чем сообщение написать

Зря на ZugDuk наезжаешь, я проверял Foobar под вайном (вывод Directsound) - всё там бит-в-бит (без Replay-Gain, без DSP, без дизеринга, громкость 100%). Под виндой проверял DS, Asio, KenelStreaming перехватчиком пакетов USB.

1. 16 бит после декодирования музыкального файла
2. преобразование 16 бит в float32
3. DSP (ослабление в регуляторе громкости, replaygain, эквалайзер и прочая обработка)
4. float32 на драйвер карты
5. карта преобразует float32 в выходной 24-битный поток

"Ну и нафиг эти ландыши"(с).
Посмотри на спецификацию
http://en.wikipedia.org/wiki/Single_...g-point_format
Мантисса у float32 всего 23 бита, плюс неявный первый бит, который всегда 1 - получаем в лучшем случае те же 24 бита. Тогда уже брать int32 и голову не морочить, если идет речь о ослабляющем регуляторе звука (т.е. не ожидается усиление, и соотв. переполнения разрядной сетки).
В случае эквалайзера int не прокатит: "а мясца в бас добавить" - привет клиппинг.

Поэтому умные люди типа Steinberg (VST SDK) и того же Foobar весь процессинг после декодирования ведут во float64. Даже если на промежуточном этапе обработки будет жесткое превышение уровня сигнала больше единицы, то 52 бит мантиссы это запас будь-здоров (запас в децибеллах считать лениво). Если следующий в цепочке стоит лимитер, то он отработает с "полными" данными, а не с огрызком (23 - N). Где N зависит от того, насколько сигнал вылез за пределы (1.0)
Так что из всех плееров разработчику Foobar`а надо памятник поставить, за нормальную архитектуру.

Offтопик:

Тут блин разработчики Wine, подлянку устроили. Перелопатили звуковую подсистему как бог черепаху, сцуке. Теперь вот думаю куда кидать силы: или DeadBeef допиливать до юзабельного состояния, или wine.

[anli]

повторяемость опыта паршивая

У меня повторяемость совершенно повторяемая - 100%.

в .asoundrc прописать алиас для alsa-plugin*а pcm.writefile

Тем самым из тракта удаляется и драйвер, и транспорт до ЦАПа, и ЦАП. Мне было интересно всё это дело услышать, понять, как что себя ведёт в натуре. Но - да, в качестве первого шага предложенный способ хорош, спасибо за идею! Правда, это только для Linux.

Зря на ZugDuk наезжаешь

Не наезжаю, Женя сам на кого хочешь наедет Лишь сподвигал проверить в условиях, именно отличных от

громкость 100%

Мантисса у float32 всего 23 бита, плюс неявный первый бит, который всегда 1

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

Тогда уже брать int32

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

весь процессинг после декодирования ведут во float64

Да, когда речь о какой-то реальной обработке (а не просто о регуляторе громкости), лучше double. Но это уже дело плагинописателей

[anli]

Offтопик:

Теперь вот думаю куда кидать силы: или DeadBeef допиливать до юзабельного состояния, или wine.

Лично мне было бы интересней безукоризненный движок у DeadBeef, нежели что-то в wine, так как последний использую только для LTspice.