В этом материале мы такую проверку как раз и сделаем, расставив все точки над «i».
Linux в бизнесе решает в основном узкоспециализированные задачи, в которые звук, видео и графика не входят (для серьезных проектов в это области используется Windows и MAC). Для обычных (домашних) потребителей, Linux является или хобби (построить ОС под себя), или бесплатной ОС, когда нет денег на Windows/MAC (например на работе, где руководство решило сэкономить на лицензиях).
Последние пару лет Linux стал более широко распространен среди обычных пользователей благодаря продажам ноутбуков, где вместо DOS («черного экрана без ничего») уже был установлен Linux. С учетом последних международных событий нет сомнений в том, что Linux и дальше будет проникать в компьютеры рядовых пользователей и получать более широкое распространение.
Теперь о неприятном для «фанатов-линуксоидов». Диалог о качестве звука часто складывается так:
— Как в Linux со звуком, он там лучше/хуже, чем в Windows?
— Конечно лучше, это же Linux, в нем ничего лишнего и он гибко настраивается!
— Да ничего подобного, у меня в Linux все плохо со звуком
— А вот и нет, у меня под Windows вообще не работает, а под Linux определилось и все супер!
— А проверяли на побитовую точность (BitPerfect)?
— Зачем? Там же все прозрачно и понятно. По логике проблемам негде взяться.
— И ни у кого подозрений даже нет?
— Ну, некоторые интересовались. Слушали и под Linux и под Windows. Под Linux большинству нравится больше.
— А гарантии или материальную ответственность кто-то дать может, что действительно все «бит-в-бит»?
— Зачем это? Ведь говорю, слушали, сравнивали, Linux лучше, какие еще гарантии? И вообще, Linux, он бесплатен…
— Но ведь Windows проверяли и он показал побитовую точность в Wasapi и если звук в Linux отличается, то значит он дефектный.
-Вы просто ничего не понимаете….
На форумах можно найти множество рекомендаций и настроек по звуковой части Linux, но вот фактических данных, что эти настройки гарантируют качество на уровне бит-в-бит (BitPerfect) нет. На дворе 2015 год, вопрос о корректности вывода данных возникает постоянно, но желающих сделать проверку самостоятельно не нашлось… А минусы лишь за подозрение в непогрешимости Linux показывают, что вопрос еще и болезненный.
В чем важность теста Linux на BitPerfect?
Правомерно ли сомневаться в качестве звуковой подсистемы Linux, если ее никто корректно до сих пор так и не проверил? Пока нет проверки и результата, что Linux работает корректно, рекомендовать Linux в состав высококачественных аудио систем то же самое, что и утверждать «на авось». К счастью, качество звука, это не точность расчетов запуска ракеты в космос, что бы сильно переживать. Или может дело в том, что подавляющее большинство использует встроенные или бюджетные звуковые карты? Кто тратит только на внешний ЦАП более $1000, обычно более привередлив и требователен к качеству звука. Если уж обсуждаются «золотые USB кабели» то уж математику ОС явно стоит проверить.
Варианты проверки на BitPerfect
Сверка записи фрагмента
Проверить систему можно разными способами, одним из которых является запись фрагмента по цифровой петле, а после в бинарном виде сверка бит в бит. Однако такой тест очень трудоемкий и требует наличие звуковой карты с цифровым входом и выходом. Дополнительно такой тест требует звукового редактора, который будет работать в определенной разрядности, а не во float данных (с плавающей запятой) для экономии ресурсов. Если верить пользователям Linux, то эта ОС достаточно распространена среди ценителей качественного звука и пусть тест и муторный, он вполне осуществимый, тем не менее его так никто и не сделал. Это говорит или о несерьезном отношении к звуку со стороны пользователей Linux (включая банальную лень), или о низкой квалификации в этой области со стороны пользователей, не представляющих, как такой тест сделать на практике.
Проверка с помощью специализированного оборудования
Второй вариант достаточно простой, взять какой-нибудь ЦАП с функцией проверки побитовой передачи — но вот беда, такой ЦАП (например Audiolab M-DAC) стоит под $1000. Если пользователь Linux стал приверженцем системы из финансовых соображений, то подобные устройства у него вряд ли есть.
Субъективное прослушивание
Остается последний вариант, это субъективное прослушивание. К сожалению, тест по определению не обладает высокой степенью точности и может давать даже заведомо ложный результат.
Прежде всего, тест должен соответствовать концепции двойного слепого прослушивания, что организовать не всегда просто.
Далеко не все звуковые карты поддерживают 44.1 кГц напрямую, очень многие (особенно популярные карты от Creative или встроенный звук) не имеют прямой поддержки 44.1 кГц — там всегда есть ресемплинг в 48 или 96 кГц. И конечно же разницу можно услышать между воспроизведением в Linux и Windows, но субъективное сравнение с такими картами – это сравнение качество ресемплеров, а ни как не концепции «бит-в-бит».
Если карта поддерживает 44.1 кГц напрямую, то можно действительно сравнить звучание подсистемы, но реально ли отчетливо услышать добавленный дизеринг (очень тихий шум) при микшировании? Это маловероятно даже на очень дорогих трактах. Т.е. мы можем придти к мнению, что все в порядке, но внутренне опасаться, что возможно на каких-то композициях мы теряем некоторую музыкальную составляющую, что система дает результат не на 100%, а на 99.99%.
С чем сравнивать? Формально, если Linux выводит звук верно, звучание должно ничем не отличаться от звука Windows из под WASAPI. Заниматься же просто прослушиванием, «нравится/не нравится» смысла нет, т.к. это будет просто выбор того звука, который нравится, а не который соответствует концепции «бит-в-бит».
Тест BitPerfect в Linux
Что бы расставить точки над «i» и фанаты Linux смогли бы прокричать «мы же говорили, что Linux самый лучший» или «ну и что, что BitPerfect нет, зато звучит то как хорошо!», автор предложил сделать проверку побитовой передачи звукового потока с помощью упомянутого выше Audiolab M-DAC, обладающего аппаратной проверкой данных. Для теста необходимо воспроизвести специальный проверочный wav файл и подать звуковой поток в M-DAC, на любой цифровой его вход (SPDIF, TOSLINK или USB). Встроенный анализатор соответственно выдает статус по BitPrefect в режиме проверки. На текущий момент для M-DAC существует два файла с разрешение 44,1 кГц 16 бит и 96 кГц 24 бит.
Предлагалось привезти компьютер с установленным Linux со звуковой картой с цифровым выходом. Альтернативный вариант – это компьютер с Linux со свободным USB портом для подключения M-DAC напрямик и соответственно передачей звукового потока по USB (вариант менее желательный, т.к. вдруг бы M-DAC не определился в системе?).
Что показательно, кто громче всех считал бредом малейшие сомнения в качестве звуковой подсистемы Linux, не посчитали необходимым поучаствовать в тесте.
Практическое тестирование
На предложение проверить Linux откликнулся ValdikSS, предоставив ноутбук с установленным Linux (KDE). Отдельной звуковой карты не было, поэтому к ноутбуку подключался M-DAC по USB. M-DAC определился сразу и ничего не помешало проведению теста.
Перед тестом в Linux была проведена отдельная проверка M-DAC в Windows из под Foobar2000. Под WASAPI из foobar2000 для тестовых файлов 44/16 и 96/24 M-DAC отрапортовал статусом “Bit Accurate”, а при выборе Direct Sound соответсвенно «Test Failed» — микширование подсистемы Windows не осталось незамеченным.
Убедившись, что M-DAC работает корректно, приступили к проверке в Linux.
Использовался Amarok с выводом через VLC, MPV и GStreamer. При настройке в PulseAudio двух поддерживаемых частот 44.1 и 96 кГц для всех плееров можно было наблюдать корректную работу автомата опорной частоты (при соответственно отключенных ресемплерах в настройках плееров). При выставлении значения регулятора громкости в 100% M-DAC отрапортовал “Bit Accurate”, что указывает на полностью корректную передачу данных от плеера до самого ЦАП.
При передаче звукового потока напрямую в ALSA, не задействуя PulseAudio, возникли сложности.
USB приемник в M-DAC принимает поток исключительно в 24 бит. При выборе WASAPI в Foobar2000, отдельно выставляется разрядность выходного потока и звук есть только при выборе 24 бит. Т.е. преобразованием разрядности занимается непосредственно Foobar2000, по сути добавляя «пустые» 8 бит. Т.к. преобразование происходит корректно, то тест с файлом для 44кГц 16 бит проходит положительно. Аналогично в Linux при выводе звука в PulseAudio, именно PulseAudio делает преобразование (и по результатам теста – корректно).
А вот в ALSA не удалось отправить 16-ти битный поток, который бы из ALSA поступил в 24 бит в M-DAC по USB и тест для 44.1 и 16 бит был провален. Тест же для 96 кГц и 24 бит прошел корректно, что дает основания считать, что если у звуковой карты на прием доступен режим в 16 бит – то будет полный порядок.
В комментариях предлагается поделится мнением, как можно конвертировать 16 бит в 24 в ALSA, если это возможно.
Впечатления со стороны
Общие впечатления автора со стороны, как пользователя Windows.
Очевидные плюсы звука в Linux
Среди плюсов можно отметить, что настройки в PulseAudio/ALSA имеют прямое отношение к любому программному плееру и соответственно количество и разнообразие плееров гораздо больше, чем плееров в Windows c настройкой Wasapi (настройка доступна только в параметрах плеера). Особо выигрышно тут выглядят видеоплееры, т.к. под Windows из видеоплееров с WASAPI пока доступен лишь Light Alloy.
Очевидные минусы звука в Linux
Отладка параметров с использованием консоли. Возможно, освоить консоль не долго. Но это лишнее время, которое потребуется потратить пользователю, вместо того, что бы получить сразу быстрый результат в Windows.
Воспроизведение DSD потока, получающего более широкое распространение последние пару лет, пока под большим вопросом.
Итог тестирования
Тест показал, что Linux действительно можно использовать в составе Hi-Fi/Hi-End систем с концепцией BitPerfect. И если раньше Linux подходил на эту роль теоретически, и давал повод для сомнений, то проведенный тест показал, что концепция BitPerfect является реальностью и доказанным фактом.
Автор Кузнецов Роман romanrex
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (52)
Halt
28.05.2015 13:06+6Hello, this is Linus Torvalds, and I pronounce PulseAudio as Pu.psh.sAddia...u..psh…
P.S.: На правах бояна; современная реализация работает куда лучше :)
SOUNDPAL Автор
28.05.2015 13:11-2Загрузил с загрузочной флешки без установки Ubunta и Росинка. Как и где добраться до настроек ASLA/PulseAudio?
mva
28.05.2015 22:01+1Например. Открыть графический микшер. В минимальном виде — kmix (если kde). И (сейчас гномеры набегут подскажут) если гном (ну, в случае убунты — у них вообще свой путь с этим их Unity).
Чуть более «продвинутый» микшер — pavucontrol для PulseAudio и alsamixer (консольный, но псевдографический) для ALSA (на самом деле, он и PA в какой-то степени умеет, ибо PA умеет быть бекендом ALSA (вот такой вот «уроборос»)).
Так же в какой-то степени «настройками аудиосистемы» можно назвать те «крутилки», которые можно обнаружить в «Параметры системы»->Мультимедиа в KDE ;)
Омские линуксоиды ещё настройками аудиосистмы могут назвать параметры ядерных модулей (драйверов, по-вашему), которые пишутся в системные конфиги или коммандлайн ядра.
В общем, уточните запрос :)
P.S. заранее прошу прошения за цветовую и шрифтовую гамму. Но, как говорится, о вкусах не спорят ;)
romanrex
29.05.2015 12:05У меня перед глазами «Linux Mint 11 Росинка (Std) x86» и «Ubuntu 15.04 desktop». Росинка выглядит более приятно…
yumka
28.05.2015 13:35+2Насчет опроса: мне кажется, что если провести такой же среди пользователей любой другой операционной системы — результат получится очень близким по той причине, что в опросе принимают участие нормальные люди. Если бы такой опрос проводился на форуме звукорежиссеров — было бы показательнее. Или если бы компоненты тракта были бы жестко зависимы от ОС.
А так… Человек, которому важно хорошее звучание, потратит больше денег на звуковой тракт вне зависимости от того, какая ОС у него в текущий момент. Железки-то перекидывать при переустановке системы не нужно.
worldmind
28.05.2015 15:16+1Я всегда был уверен что звук в линуксах круче т.к. ядро даёт меньше задержке и это важно в каких-то вариантах использования (видимо реал-тайм эффекты). Где-то читал про это, но ссылок не имею — давно было.
Gorthauer87
28.05.2015 17:22+1Тут всё-таки отсутствие лишнего ресемлинга тестировали, а задержки это вообще другая епархия. Там уже начинаются пляски с Jack, работой в обход pulseaudio, который дополнительные задержки любит вносить.
vaslobas
28.05.2015 21:00Вот это нагуглилось сходу appleinsider.ru/from-readers/nam-pishut-pochemu-muzykanty-vybirayut-apple.html
ValdikSS
28.05.2015 21:26+1Вообще, серьезные ребята устанавливают минимальный буфер в ALSA и используют ядро с Realtime-патчами. Я раньше много играл в ритм-игру Osu, так что теперь знаю немного об особенностях ALSA (и Wine). Скажем, 10 мс добиться вполне реально. Меньше — труднее.
dbanet
29.05.2015 06:46А каким образом эту задержку вообще измерить?
ValdikSS
29.05.2015 09:35Самый простой способ — подключить выход аудиокарты к ее же входу.
dbanet
30.05.2015 00:11Тогда в измерениях будут задержки, вносимые во время захвата звука. Да и всё равно непонятно, каким образом это (программно) осуществить.
Sadler
30.05.2015 22:19Тогда подключите к какой-нибудь ардуине или другой подобной машинке, тактовая частота которой однозначно много больше частоты выходного сигнала. Так можно измерить задержку с заранее заданной точностью.
dbanet
01.06.2015 05:45А как предлагаете синхронизировать часы? Наверное, можно подключить ардуинку (или что-нибудь подобное) по ещё какому-нибудь интерфейсу, например, последовательному. Потом слать с ардуины echo request, запуская секундомер. Компьютер шлёт echo reply, по прибытии которого останавливаем секундомер. Медианное значение, в принципе, можно считать более-менее точным лагом компорта.
Проигрывание начинать, выслав синхро-символ по последовательному порту. Тогда на ардуинке, сделав поправку на лаг порта, можно получить и лаг звукового выхода.
Вот чтобы такой велосипед не изобретать, я и решил спросить ValdikSS, который совсем недавно делился своим экспертным мнением. :)
Только что-то всё равно методики замера (а может быть, и вовсе готового решения, как в этом посте) лага я у него не добился. :(ValdikSS
01.06.2015 13:37Я не знаю, к сожалению, как изменять задержку правильно. Практически все тесты, что я находил, либо измеряют внутреннюю задержку драйвера (задержка между началом воспроизведения и записи, так делает, например, latency.c из alsa-lib), либо просто измеряют loopback latency manual.audacityteam.org/index.php?title=Latency_Test
Sadler
01.06.2015 13:43Никак не синхронизировать. Отправлять данные на вход с ардуины и забирать с выхода тоже ардуиной. Затем найти смещение сигналов в тактах ардуины простейшей кросскорреляцией. Минус только в том, что получим задержку всего тракта: от входа до выхода, а не отдельных его участков.
dbanet
01.06.2015 19:11То есть, выполнять захват звука, посылаемого ардуиной, на компьютере, перенаправляя его на звуковой выход? По-моему, это не даст выигрыша в погрешности в сравнении с предложенным ValdikSS вариантом, когда сгенерированный на компьютере звук покидает звуковой выход, напрямую подключенный к звуковому входу, с которого происходит захват и анализ лага, но даст дополнительную сложность в постановке эксперимента.
dbanet
30.05.2015 00:19Честно говоря, мне захотелось бенчмаркнуть звуковую подсистему OS/2. Дело в том, что помимо того, что этот компонент OS/2, фактически, не обновлялся очень давно, он также вообще никогда не переписывался, появившись, вероятно, где-то с Warp 3. То есть, это будет бенчмарк кода двадцатилетней давности на современном железе. Ну, вы поняли. :)
Gorthauer87
28.05.2015 17:56Интересно было бы ещё макось проверить и какую-нибудь ось с OSS в качестве звуковой подсистемы, к примеру, FreeBSD.
romanrex
28.05.2015 18:03Да, это было бы интересно. Если есть желающие, то добро пожаловать в гости. Требуется или наличие звуковой карты с SPDIF/TOSLINK или USB входом, к которое можно подключить Audiolab M-DAC
calx
28.05.2015 19:21Никто не измерял линукс на bitperfect-ность, потому что и так понятно, что звук — самое слабое звено в этой системе. Это не так заметно с единственной картой. А вот, например, настройка не особо редкой конфигурации: встроенная, плюс внешняя USB, плюс USB-видеокамера с микрофоном — может очень быстро разбудить в человеке зверя. Ну и приличного аудио-софта под линукс почти нет.
ValdikSS
28.05.2015 21:23+1Я вынужден с вами не согласиться. Да, возможно, проблемы имеются, но точно вс настолько плохо, как это описываете вы. Что у вас за проблемы-то? Я как-то уживаюсь с 4 аудиовыходами (встроенный от Creative, USB DAC иногда, DisplayPort и TCP-туннель до колонок на домашнем сервере через PulseAudio), особых проблем нет.
calx
28.05.2015 23:09ALSA совершенно не предназначена для какого-либо Plug-n-play. Настроил, заработало, больше никогда не трогай. Две звуковые карты, использующие usb_audio, настроить мне так и не удалось (проблемы с тем, чтобы указать карту по-умолчанию). От курения мануалов кашель не проходил неделю. Куча недоделанных, несовместимых или безнадёжно устаревших API для работы со звуком. По сравнению с тем, что доступно пользователю Windows (за Mac OS X не скажу, но подозреваю там как минимум не хуже), это мрак и ужас.
ValdikSS
28.05.2015 23:15+1Для Plug'n'Play есть PulseAudio, он делался в том числе и для этого. Карта по умолчанию указывается через defaults.ctl.card и defaults.pcm.card.
Ivan_83
28.05.2015 23:24+21. Винду тоже далеко не все покупают, так что нищебродов среди её пользователей намного больше :)
2. Сваливают с винды ещё и потому что повседневные задачи меняются на такие, что в винде решаются через жопу а в других ОС с этим проблем нет.
3. Без пульса трудновато жить с несколькими аудиокартами (включая выход по хдми, юзби веб камеру как микрофон).
4. ALSA несколько более сложная в программировании, чем OSS:
github.com/ivan-83/FreeRDP/blob/master/channels/rdpsnd/client/alsa/rdpsnd_alsa.c
github.com/ivan-83/FreeRDP/blob/master/channels/rdpsnd/client/oss/rdpsnd_oss.cromanrex
29.05.2015 11:42Если не секрет, какие задачи для обычного пользователя (не сугубо профессиональные) на Linux решаются лучше? Т.е. преимущества для рядового пользователя?
Ivan_83
30.05.2015 00:42+2Для рядового — может старые игрушки, у меня много перестало работать после перехода на х64, часть ещё под 2к3х64, и ещё что то доломалось под семёркой.
В wine пошёл nfs3, почти что nfs4 — чего то мелкое ещё не дожал в нём. Андеграунд тоже, но он вроде и не ломался.
Лично для меня плюсы:
— openssh умеет все современные крипто алгоритмы и есть выбор между тем как оно выглядит, ssh монтируется и результат не отличается от обычных папок.
— отпала необходимость в 1-2 виртуалках с линуксами, которые я использовал чтобы иногда стримить в домашнюю сеть мультикаст из файла.
— могу собирать софт на основном компе, а не на домашнем сервере (он у меня экономичный и там всё дольше)
— нет привязки к железу — могу апгрейдится/даунгрейдится с минимумом простоя/дискомфорта.
— нет привязки к архитектуре: могу свалить хоть на мипс/арм и не так чтобы сильно всё изменится
— бОльшая свобода действий и нет дебильных ограничений, типа зеркальный рейд можно только в серверной венде или через секс с драйвером контроллера (часто тот же программный только хуже чем средствами ОС)
— более сильное и доверительное крипто, и разнообразия средств больше
— легкость переноса настроек: достаточно перекинуть текстовые файлы чтобы поделится настройками
— через 5 лет семёрка того, от вида восьмёрки мне плохо, мягко говоря :)
— мой любимый UPS APC тут всё ещё поддерживается, винда похерила поддержку COM бесперебойников в семёрке, а софт апц — перебор (я пробовал накорябать свой драйвер батареи, но в винде это не так просто, да ещё и сертификат нужен для подписывания, про инициативу реакт ос я не знал когда забрасывал)
— софт из портов: нет необходимости искать нужное по всяким помойкам и надеяться что оно без вирусов, и софта банально больше чем есть под винду (я про всякие сетевые утилиты)
Минусы:
— кой чего глючит, но здесь есть куда жаловаться и оно фиксится, в крайнем случае можно и самому, как я сделал с FreeRDP: www.netlab.linkpc.net/wiki/ru:software:freerdp:sound, amdtemp: www.netlab.linkpc.net/wiki/ru:software:freebsd:amdtemp и тп…
— кое что не имеет аналогов и пришлось тащить, например, Miranda NG, пришлось патчить чтобы она в вайне заработала и разбираться как вообще этим вайном пользоваться, в итоге всё получилось: wiki.miranda-ng.org/index.php?title=Miranda_%D0%BF%D0%BE%D0%B4_Wine
— кое для чего нужна винда, всё ещё, теперь в вируалке (лего маиндшторм — под вайном пока не пашет)
— приличной замены IPTV Player от борас не нашлось, пришлось писать своё. Пока ещё рановато выкладывать, но меня вполне устраивает. Сразу закладываюсь на систему плагинов, похожую на ту что в миранде.
— некоторые вещи всё ещё не совсем привычны (15 лет винды и 0,5 FreeBSD + xfce)
— со звуком не так удобно (когда кроме одной звуковухи есть ещё и вебка с микрофоном и тп), а пульс ставить и разбираться совсем не хочется
— не нашёл чем заменить 7-зип/винрар гуй к архиваторам и не подобрал просмотрщик картинок на подобии фастстоуна, привычной читалки пдф (типа суматры) тоже не нашёл (есть окуляр, помню удобный, но QT не хочу барахлить в систему).
— пришлось отказаться от скайпа (остался только в гандройде), а utox ещё не совсем дорос (думаю ещё пол годика подождать)
RMV1983
31.05.2015 12:45>…не нашёл чем заменить 7-зип/винрар гуй к архиваторам…
Попробуйте file-roller, хотя и не идеал, но работает.
Удобный «просмотрщик картинок» тоже пока не нашёл. Пользуюсь comix, хотя он и для другого предназначен.
Вообще для гнома и xfce (GTK+): Evince — эдакий универсальный монстр. PDF поддерживает.
По поводу миранды — ничего к сожалению подсказать не могу. У того же пиджина — куча мелких проблем.Ivan_83
31.05.2015 14:06+1file-roller — нашёл, и пользуюсь, не фонтан, мягко говоря после 7zip/winrar, иногда не понимает некоторые форматы, иногда падает.
GPicView пока пользуюсь, на уровне «просмотр факсов и снимков» из винды, чуть получше.
Miranda NG — теперь работает, основные косяки я вылечил (патчи уже в кодовой базе миранды), остальное мне не заметно/не мешает.
KivApple
29.05.2015 02:10Вопрос насчёт минусов — потребовалась ли ручная правка конфигов при выводе звука через pulseaudio или же все решилось через gui? Если второе, то это не такой уж минус, ибо для всяких тонких настроек (типа сверхнизких задержек, которые теоретически даст alsa) лезть в потроха системы не так страшно (в той же винде для некоторых задач нужно вносить изменения в реестр). Обычного пользователя менять звуковую подсистему никто не заставляет.
ValdikSS
29.05.2015 09:37+1Я менял параметры
default-sample-rateиalternate-sample-rateв /etc/pulse/daemon.conf. Возможно, для этого есть GUI, я специально не искал.Gorthauer87
29.05.2015 10:21Кстати, пульса же умеет в хомяке конфиги, может лучше тогда системный не трогать?
AEP
29.05.2015 10:49+3А вот ответ на вопрос про преобразование количества бит средствами ALSA: использовать имя устройства, начинающееся с «plughw:». Например, plughw:1
Ну и на самом деле тест с таким дорогим оборудованием можно было не проводить. Любая карта, которая успешно пропускает AC3 или DTS на ресивер, является по определению BitPerfect — а ресивер у пользователя, который задается таким вопросом, скорее всего, есть.
Сам вопрос про BitPerfect считаю академическим. Мое личное мнение: он нужен только для пропуска AC3 и DTS на ресивер. Я все равно пропускаю весь звук через фильтр (цепочка: pulseaudio -> jack -> brutefir -> alsa), чтобы частично скомпенсировать объективные акустические недостатки комнаты, и вам того же буду советовать, когда появится «родная» поддержка в PulseAudio (если нет такой же функции в ресивере). Фильтр построен с помощью измерительного микрофона и drc-fir.sourceforge.net/doc/drc.htmlKlukonin
29.05.2015 11:49Зачем из пульаудио в джек? Можно же сразу.
AEP
29.05.2015 11:52+1Цель — передать звук из PulseAudio в BruteFir (поскольку другой программы для свертки звука с FIR-фильтром нет). BruteFir умеет только быть либо JACK-клиентом, либо записывать со звуковой карты, либо читать из файла. Поэтому JACK оказался наименее затратным способом выполнить стыковку этих программ.
Klukonin
29.05.2015 11:54Cadence используете?)
AEP
29.05.2015 12:02Нет. Самодельные скрипты запуска всего этого добра, хотя знаю, что должен или изучить LADISH, или добавить полный аналог BruteFir в PulseAudio.
Klukonin
29.05.2015 13:12А чего там особо изучать О_о.
Мне очень нравятся инструменты графические которые есть. Они избавляют и от скриптов и от копаний в кишках.
romanrex
29.05.2015 12:40Проверка через ресивер возможно и дешевле, но не соглашусь, что есть ресиверы у тех, кто задается вопросом качественного звука. Ресивер есть в основном у тех, кто строит домашний кинотеатр. Для высококачественных систем используется стерео и ресивер часто отсутствует, как «несерьезный усилитель» — в стерео слабый, а многоканальность ненужная. Например у меня M-DAC есть, а ресивера нет, только отдельные стереоусилители в Bi-Amp системе с активным фильтром. Вторая причина — многоканальный звук в AC3 или DTS — это аналог многоканального mp3, что не так круто как wave/flac и т.п.
Для акустики помещения коррекция безусловно полезна и это отдельная большая тема, но это не отменяет принципы BitPrefect, т.к. одно дело вставить алгоритм в чистую передачу данных, или в уже перекореженную до и после алгоритма. Ведь лучше это построить в той конфигурации, где других лишних преобразований нет.
Пользователи наушников, отдельная история — обычно необходимости в правке АЧХ нет.
В Вашем случае, автомат опорной частоты работает (больная тема в Windows для аналогичных решений через WDM->ASIO)?AEP
29.05.2015 12:54В Вашем случае, автомат опорной частоты работает (больная тема в Windows для аналогичных решений через WDM->ASIO)?
Нет. JACK работает с фиксированной (задаваемой при запуске) частотой дискретизации. Ну и этот автомат все равно не имел бы смысла, так как тогда бы было необходимо иметь (или генерировать на лету тем же ресемплингом) отдельный фильтр для каждой частоты дискретизации. С ресемплингом фильтра мы получили бы искажения того же толка, что и с ресемплингом фильтруемого звука, т.е. овчинка не стоит выделки.
P.S. ресивера у меня действительно нет, есть интегральный усилитель Rotel RA-1570.romanrex
29.05.2015 13:13+1Я ранее экспериментировал с концепцией «цифрового Bi-AMP» используя SpinAudio в Windows, перекидывая поток из WDM в ASIO (ASIO для автомата частоты приоритетнее), необходимость переключать частоту сильно мешала, т.к. не хотелось постоянно за этим следить.
cepreu4habr
29.05.2015 13:14+2Может я профан в звуке, но мне интересно. Запустить Linux под виртуалкой с выводом аудио в WAV-файл и последующим сравнением этого файла с оригиналом — это плохой тест на BitPerfect?
Вроде это достаточно дешевый способ проверки, не нужно никакого специального оборудования.romanrex
29.05.2015 13:27+2Перехватываться поток где будет, на выходе плеера или входа в звуковую карту? В Windows в некоторых плеерах была возможность выводить Wav файлом поток, но это не затрагивает звуковую подсистему и соответственно не дает конечный ответ.
AEP
29.05.2015 14:09+3Перехватываться средствами виртуальной машины. Т.е. что именно пишется в буфер эмулируемого звукового контроллера. Если используется KVM, то:
export QEMU_AUDIO_DRV=wav export QEMU_WAV_PATH=$HOME/tune.wav
и вперед.
conformist
31.05.2015 17:52Amarok не совсем удачный выбор для теста, в том же deadbeef есть специальная опция для посылания на вывод 24-битного сингнала для 16-битных файлов.
ValdikSS
01.06.2015 13:18Amarok, по сути, не является тем, что играет звук. Он использует фреймворк phonon, к которому есть бекэнды MPV, VLC и GStreamer. Xine еще есть, но про него уже все давно забыли.
Arsain
Под Windows тоже есть вариант вывода через WASAPI почти для любого видео-плеера. Это ReClock. Если его выбрать в качестве аудио-рендера в плеере, то проблема решается. Правда я не знаю, насколько хорошо написан сам ReClock, не проверял.
romanrex
Да же неясно, что проще под видео настроить, Windows через ReClock или Linux…