Когда я начинаю говорить про настройку звука в Linux, то встречаю непонимание или отсутствие интереса, ведь люди представляют себе это как эквалайзер или какие-то ползунки с улучшайзерами, за которые 5 минут подёргал и настроил ещё лучше! На самом деле, нет ничего готового: никаких ручек и ползунков, а только файлы конфигов, в которые нужно самому придумать, что написать! Здесь я хочу по порядку рассказать о богатстве неочевидных возможностей, которые я рыл много лет и подбирал на слух.
ПРЕДУПРЕЖДАЮ! Статья будет длинная, без красочных картинок, но интересная для тех, кто интересуется звуком! Это то, что не доступно простым обывателям, которые ни в чём не разбираются, а только выпендриваются дипломом троечным в комментариях.
1. GRUB - загрузчик Linux
Если кратко, то загрузчик - это программа, которая запускает операционную систему с заданными параметрами. Это, пожалуй, самый простой конфиг в настройке, но по важности для звука он стоит на первых местах!
Нужно добавить или заменить всего 2 строчки в файле /etc/default/grub
GRUB_RECORDFAIL_TIMEOUT=0
GRUB_CMDLINE_LINUX_DEFAULT="quiet threadirqs hpet=force clocksource=hpet maxcpus=1"
А затем применить изменения и перезагрузить систему:
sudo update-grub
sudo reboot
Первая строка к звуку не относится. Она нужна, чтобы компьютер не ждал выбора пользователя перед запуском системы 30 секунд (для ПК без монитора это важно), а на опциях во второй строчке остановимся подробнее:
- quiet - стоит по умолчанию, для звука интереса не представляет, а просто отвечает за загрузку системы без splash-изображения
- threadirqs - эта опция загрузчика позволяет превратить IRQ-потоки оборудования в процессы реального времени!
- hpet=force и clocksource=hpet - эти 2 опции включают принудительно точные часы HPET (без force иногда hpet может быть не виден в системе), вместо менее точных TSC. Это увеличит точность звука, разницу вы сразу заметите!
- maxcpus=1 - как нетрудно догадаться, эта опция оставляет только одно ядро процессора. Я уже писал в статье о настройке BIOS, что для звука лучше оставить только одно рабочее ядро процессора, иначе процессы будут работать на разных ядрах, в свою очередь у каждого из которых свои собственные часы, которые могут немного расходиться, в итоге теряем в точности звука. Для наших целей 1 ядра даже Celeron выше крыши!
Пробовал ещё некоторые опции, но на мой слух, они делают только хуже, хотя по логике должны помочь улучшить его. Можете попробовать на досуге:
- mitigations=off - отключает проверку ошибок, на которые процессор тратит ресурсы. Мне показалось, звук стал хуже, не использую. Возможно, дело именно в моём компьютере.
- usbcore.autosuspend=-1 - делает невозможным автоотключение питания по usb (актуально для ЦАПов, и действительно может повлиять на звук, хотя на встройке я не заметил улучшений).
- acpi=off - отключает систему управления питанием и оборудованием. С одной стороны, это должно положительно повлиять на звук, ведь отключается лишнее устройство на PCI шине, освобождая ресурсы для звука. Но, одновременно у меня появилось куча проблем - шумно работал вентилятор на максимальных оборотах, и не работали кнопки выключения. Мне такое не надо! И хотя была разница, оно того не стоит. Однако, вместо этого я задвинул приоритет ACPI - он при этом работает, как обычно, но ресурсов отнимает мало, как будто выключен.
Влияние GRUB на windows
Имейте ввиду, что устанавливая linux рядом с windows, он тоже станет загружаться через GRUB, а значит принимает и все параметры, которые вы задавали для linux (1 ядро, точные часы, и много неизвестного мне). Это для меня было открытием, но в данном случае, звук даже в windows значительно улучшится. Этот факт надо иметь ввиду, если будете сравнивать linux и "улучшенный" windows. А проверить очень просто. Есть утилита winTimer, которая показывает частоту таймера, и msconfig.exe, в котором перестанет быть доступен выбор числа ядер. Может быть, мне показалось, но многие вещи, которые я настраивал в linux (например sysctl.conf), тоже влияли на звук в windows, хотя они к ней не относятся.
Кстати, из наблюдений, на одном ядре процессор сильнее нагревается. Вероятно, потому что работая один, дольше выполняет задачи, и сильнее нагружается. А когда их несколько, и нагрузка распределяется равномерно между ядрами, то времени те же задачи отнимается в разы меньше, и меньше факторов, повышающих температуру.
В частности, именно поэтому, для звука нужен отдельный компьютер! Ведь настройки компьютера для наилучшего звука и для наибольшей производительности - разные вещи.
2. Параметры ядра
В ядре linux множество параметров, которые уже заданы изначально, но некоторые из них сильно влияют на звучание и легко поддаются настройке на слух. Расскажу про эти параметры и их особенности в системе linux mint.
Список параметров ядра можно получить по команде "sysctl -a", их тысячи. Все я конечно же не пробовал, собирал информацию по крупицам в интернете, тестировал, и даже нашёл несколько сильно влияющих параметров на свой слух.
Как задавать параметры ядра
Параметры можно задавать 2 способами (если знаете ещё, напишите в комментариях):
- указать строчку в файле /etc/sysctl.conf, например: "vm.overcommit_memory=2" (значение всегда будет черпаться из этого файла при запуске системы),
- выполнить команду "sudo sysctl -w vm.overcommit_memory=2" (при перезагрузке будет сбиваться на начальное значение, которое было в ядре).
Чтобы услышать изменения в звуке, всегда необходимо перезапускать плеер MPD!
Странности параметров ядра linux для звука
Однако со звуком в плеере MPD, который используется для прослушивания в системе Linux, не так всё просто:
1. Влияние "сдвигов", о которых подробно писал здесь (кстати, как раз на примере sysctl.conf)
2. Не могу с уверенностью сказать, как на самом деле, но на слух очевидно, что плеер MPD и система linux воспринимают параметры ядра не одинаково! Если один и тот же параметр задать сначала через sysctl, а потом поменять значение командой sysctl -w, то после перезапуска плеера звучать музыка будет совершенно не так, как если задать их через sysctl. Я предполагаю, что плеер считывает значение из sysctl.conf при каждом его перезапуске, а система только один раз при загрузке или по команде. Возникает некий "диссонанс", но именно он иногда может давать аудиофильский звук.
3. Некоторые параметры ведут себя не предсказуемо, иногда некоторые из них полезно "передёрнуть", например, vm.overcommit_memory (это стратегии выделения памяти) сначала на 2, потом на 0, затем снова 2 - это будет по параметрам одно и то же, а звучит совсем по-другому.
Советую начать с этих параметров
Как и писал, в интернете часто советуют параметры для улучшения звука, и даже по логике они должны улучшать звук, но на практике иногда получается даже хуже, поэтому я от них отказался (но надо пробовать обязательно). Например, часто советуют увеличить параметры системных таймеров:
sudo sysctl fs.inotify.max_user_watches=8192
sudo sysctl fs.inotify.max_user_instances=65536
echo '2048' >> /sys/class/rtc/rtc0/max_user_freq
Но как оказалось, первые 2 и так уже имеют высокие значения, а третий делает только хуже (хотя по умолчанию значение всего 64, странно, не правда ли?). Решил больше их не трогать.
Еще часто советуют увеличить параметры для жестких дисков (чтобы реже к ним обращаться), но мне тоже это не показалось лучше, но люди же советуют:
sudo sysctl vm.dirty_writeback_centisecs = 100000
sudo sysctl vm.dirty_expire_centisecs = 100000
Самые главные параметры, которые я использую в sysctl, выглядят примерно вот так:
vm.overcommit_memory = 2
vm.overcommit_ratio = 53
vm.swappiness = 8
dev.hpet.max-user-freq = 4125
Немного сведений о них:
vm.overcommit_memory - стратегии выделения памяти, их несколько, и логика мне не до конца понятна по описаниям в интернете, однако на звук очень сильно влияет!
vm.overcommit_ratio - это просто количество виртуальной памяти в процентах от физической. Влияет - не сомневайтесь! Как - другой вопрос, на который не могу ответить, а только слабо догадываться.
vm.swappiness - это процент виртуальной памяти, который использует система в своей работе.
dev.hpet.max-user-freq - это самый главный параметр, задающий частоту таймера hpet. Он влияет на звук больше всего. Значения долго подбирались на слух, они не случайные, рекомендую пробовать: 4125, 4445, 4495, 4497, 4499, 4501. Именно этот параметр больше всего подвержен "сдвигам", о которых говорилось в начале, и именно его иногда задаю одновременно двумя способами (разные значения), потому что так лучше.
Сильно влияют параметры, которые нашел на слух (не меньше, чем sysctl, но наверняка тоже подвержены "сдвигам" - был прецедент, когда не знал про них):
sudo sysctl -w vm.admin_reserve_kbytes=310773
sudo sysctl -w vm.vfs_cache_pressure=3000
Для любознательных, были найдены на слух ещё несколько экспериментальных параметров, но я почему-то от них оказался или напрочь забыл:
sudo sysctl -w vm.dirty_background_ratio=3
sudo sysctl -w vm.dirty_ratio=26
sudo sysctl -w vm.extfrag_threshold=677
3. Приоритеты IRQ и латентность
Тема приоритетов оборудования очень важна и НЕ сложна для понимания, но достаточно трудоёмка для применения. Однако, можно просто сделать по аналогии со мной, или вовсе использовать мои минимальные простые настройки для компонента rtirq-init - от них будет много пользы.
Я уже писал в статье про BIOS, что в компьютере множество устройств, подключенных к шине PCI: sata- и usb-контроллеры, wifi- и ethernet-адаптеры, видео- и аудио-карты, ACPI (система управления питанием и оборудованием), таймер, устройства связи между устройствами и другие (нередко в нескольких экземплярах, как USB-контроллеры).
Пакет RTIRQ-INIT
RTIRQ-INIT - это просто автоматический скрипт, который выставляет приоритеты звукового оборудования. Однако, чтобы он работал, в загрузчике должна стоять опция threadirqs. Эта опция превращает IRQ-потоки оборудования в процессы реального времени, благодаря чему мы и сможем ими управлять!
Установите пакет:
sudo apt-get install rtirq-init
Теперь вы можете видеть приоритеты своего оборудования по команде:
/etc/init.d/rtirq status
У rtirq-init есть свой собственный конфиг /etc/default/rtirq, который по умолчанию уже немного настроен (далеко не идеально, но сомневаться в улучшении звука не придётся), поэтому вы сразу ощутите на слух его работу! Однако, конфиг можно улучшить, потратив минимум усилий. Он будет выставлять основные приоритеты, и дальнейшая ручная доводка (как у меня) может не понадобиться. Это даст 80% результата! Я пропустил много строчек комментариев в начале:
RTIRQ_NAME_LIST="rtc mei_me"
# Highest priority.
RTIRQ_PRIO_HIGH=95
# Priority decrease step.
RTIRQ_PRIO_DECR=0
# Lowest priority.
RTIRQ_PRIO_LOW=51
# Whether to reset all IRQ threads to SCHED_OTHER.
RTIRQ_RESET_ALL=0
# On kernel configurations that support it,
# which services should be NOT threaded
# (space separated list).
RTIRQ_NON_THREADED="rtc mei"
# Process names which will be forced to the
# highest realtime priority range (99-91)
# (space separated list, from highest to lower priority).
RTIRQ_HIGH_LIST="i801"
# Save/restore state file path.
#RTIRQ_STATE=/var/run/rtirq.state
Чтобы новый конфиг применился, нужно перезапустить скрипт (или перезагрузиться):
sudo /etc/init.d/rtirq restart
Тонкая настройка приоритетов
Поскольку оборудование отличается на разных компьютерах, придётся много экспериментировать и поработать вручную. Ведь я не ограничивался этим простым скриптом с исправленным конфигом, а на слух настраивал приоритеты, и записал эти команды в собственный скрипт /etc/init.d/reboot_change, который запускается при запуске системы. Вот этот фрагмент:
sudo chrt -f -p 97 $(pgrep -f "rtc0")
sudo chrt -f -p 99 $(pgrep -f "snd_hda")
sudo chrt -f -p 98 $(pgrep -f "i801")
sudo chrt -f -p 99 $(pgrep -f "mei_me")
sudo chrt -f -p 95 $(pgrep -f "ahci")
sudo chrt -f -p 44 $(pgrep -f "xhci")
sudo chrt -o -p 0 $(pgrep -f "ehci")
sudo renice -n -11 $(pgrep -f "ehci")
sudo chrt -o -p 0 $(pgrep -f ".-ath9k")
sudo renice -n -12 $(pgrep -f ".-ath9k")
sudo chrt -o -p 0 $(pgrep -f ".-acpi")
sudo renice -n 10 $(pgrep -f ".-acpi")
sudo chrt -o -p 0 $(pgrep -n ksoftirq)
sudo renice -n 9 $(pgrep -n ksoftirq)
sudo chrt -f -p 44 $(pgrep -f "ehci")
Надеюсь, вы достаточно умны, чтобы разобраться и сделать по аналогии. Хотя, возможно, многих и так устроит!
Кроме того, некоторое ненужное оборудование (модули) можно совсем отключить.
Начальные сведения о приоритетах
В системе линукс есть простые приоритеты (NICE) и реального времени (FIFO). Они действуют для всех процессов в системе, но всё подряд настраивать жизни не хватит. Мы будем настраивать приоритеты только для IRQ-прерываний (PCI-устройств компьютера). Все они борются за то, чтобы выполнять задачу сиюминутно, но это невозможно и не нужно (дело не в нагрузке процессора - она даже на Celeron редко превышает 5%, а в чём-то другом). Задача сделать, чтобы отвечающие за звук процессы выполнялись в первую очередь, а остальные отключить или понизить их приоритет (по остаточному принципу: есть немного ресурсов - выделить, нет - пускай отдыхает).
Можно провести аналогию со скачиванием сериала. Если ничего не настраивать, все 100 серий из 5 сезонов имеют одинаковые приоритеты, и по фрагментам одновременно загружаются. Вы не сможете посмотреть ни одну серию, пока все они полностью не скачаются. Но можно поступить иначе - дать высокий приоритет первым сериям, и низкий последним сезонам. Тогда, вы сможете почти сразу начать смотреть сериал по порядку с 1 серии, а пока вы их смотрите - остальные уже докачаются. Это ведь лучше, не так ли?
Так же и в настроенном на звук компьютере. Однако, есть устройства, которые со звуком связаны, хотя и не напрямую. Поэтому не получится ограничиться высоким приоритетом только у звуковой карты. Нужны и системная шина, и таймер времени, и много вспомогательных устройств. У каждого устройства должно быть своё место, и каждое влияет на все остальные. Именно это и есть главная сложность. Логики при этом может никакой не быть - не всегда самый высокий приоритет даёт самый лучший звук. И нельзя бездумно всем подряд устройствам его дать, иначе и смысл пропадает.
Список команд, которые меняют приоритеты
Чтобы изменить приоритет реального времени (FIFO) на другой, нужна команда:
sudo chrt -f -p 90 20
Здесь 2 числа для примера: первое (90) - это приоритет реального времени от 1 до 99, а 20 - это pid процесса (их можно найти в "/etc/init.d/rtirq status" для pci-оборудования или "ps -alx" для всех процессов).
Для перехода с обычного приоритета на реальное время ничего предварительно делать не нужно - можно сразу применять команду выше.
Простые приоритеты (NICE) задаются командой:
sudo renice -n 0 20
Здесь 2 числа для примера: 0 - это приоритет от -20 (самый высокий) до 19 (самый низкий), а 20 - это pid процесса.
Кстати, чтобы ставить самый высокий приоритет -20, нужно настроить права пользователя и security limits.
Для перехода с реального времени на обычный приоритет, сначала нужно сбить процесс командой, а уже потом устанавливать обычный приоритет:
sudo chrt -o -p 0 20
где 20 - это pid процесса, а только затем:
sudo renice -n 0 20
Ещё одна сложность, что pid в системе могут меняться после перезагрузки, поэтому вместо чисел нужно использовать шаблоны. Это отдельное творчество, и у меня не всегда получается с 1 раза, но можно приловчиться, например:
sudo chrt -o -p 0 $(pgrep -f $(grep snd_hda_intel:card0 /proc/interrupts | cut -d: -f1)-snd_hda)
Сложность в том, что по шаблону система может найти сразу несколько процессов, и вы поменяете совсем не тот приоритет (хотя иногда из этого получаются выдающиеся результаты).
Я понимаю, что вы не захотите в этом разбираться. Тяжело! Просто хотел показать, насколько сложно настроить звук в linux, и какие трудности я преодолел.
Latency (Латентность) и её настройка
Сигналы от устройств на PCI-шине обрабатываются поочередно, отнимая ресурсы у остальных. Когда ресурсов не хватает, и выходит отведённое время, то словно на экзамене - забирают недописанное сочинение. Латентность - это время, на которое оно может задерживать очередь, чтобы закончить задачу. Информацию об этом я встречал не часто, но именно по этой логике звуковой карте дают максимальное значение ff (это 16-битное число), а всем остальным устройствам 00.
Кстати, чтобы задавать латентность, нужно отключить в BIOS secure-boot, иначе не сработает.
Латентность можно установить любую в диапазоне 00 - ff. Чтобы изменить латентность, например, звуковой карты, нужно знать её идентификатор, который можно посмотреть в списке PCI-оборудования с помощью команды:
lspci -v
Например, чтобы задать ей максимальный приоритет ff, команда примет вид:
sudo setpci -v -s 00:03.0 latency_timer=ff
А чтобы задать минимальную латентность сразу у всех устройств (как рекомендуют, но я с этим не согласен):
sudo setpci -v -d *:* latency_timer=00
От себя добавлю, что для своего компьютера латентность могу не настраивать, однако иногда для звуковой карты на слух лучше всего латентность da или de, df, но совсем не ff.
4. Права доступа
Права для меня всегда была самая не желательная тема в Linux - сначала долгое время старался её избегать (не хотел разбираться и надеялся, что это не сильно влияет). Под правами я имею ввиду не только права файлов (чтение, запись, исполнение, собственник), но и принадлежность пользователей к группам. Хотя в принципе понимаю, для чего они нужны, например, на промышленном предприятии, но для музыки дома я считал их излишеством. К сожалению или к счастью, но некоторые права очень заметно влияют на звук.
Я выделил 6 основных сущностей, сильно влияющих на звук: music (мой пользователь), root, sudo, audio, adm, pulse. Все они представляют из себя одновременно и группы, и пользователей, которые могут в эти группы входить. Я много экспериментировал, удаляя и помещая пользователей по этим группам и слушая различия. Но долгое время не знал главного - об этом далее.
А ещё, они у меня отняли много времени, потому что я не знал их особенностей, даже когда узнал об их влиянии и настраивал звук. Только спустя столько лет, я наконец понял, почему безупречный звук ускользал от меня, и потом делая то же самое, не мог его вернуть! Обо всём по порядку.
4.1 Права файлов и директорий
С файлами и папками всё просто, хотя я и потерял уйму времени, пока понял их важность для звука у некоторых конфигов (лишь в этом году заметил). Как видно, все конфиги, которые мы рассматриваем в целях улучшения звука, по умолчанию имеют собственника root:root, права почти у всех 644, кроме shadow (640), gshadow (640) и созданного нами же автоматического скрипта reboot_change (задали 777).
Когда вы копируете файл, а он уже существует, то права остаются от имеющегося, а содержимое - от нового. Но если вы удаляете старый файл, а затем копируете или создаёте на его месте новый, то права наследуются от донора или будут как у нового. Я этого не знал, и долго не мог потом вернуть звук, который мне нравился после долгих настроек, потому что права внезапно менялись после моих долгих поисков звука. Только недавно понял эту грубую ошибку.
Самые чувствительные к правам файлы - это /etc/asound.conf и /home/music/.asoundrc - нужно следить, чтобы права были 644, иначе звук потеряет остроту и прозрачность. Просто не пренебрегайте правами файлов, и всё будет гладко! Все подряд испытывать не пробовал, возможно, некоторые тоже будут так себя вести.
Для установки своих прав, например, /etc/asound.conf, используется простая команда:
sudo chmod 644 /etc/asound.conf
Кстати, права папки с музыкой тоже влияют на звук.
4.2 Права пользователей
А насчёт принадлежности пользователей к группам немного сложнее. Логика влияния прав на звук частично есть, однако для наилучшего звука её нужно отключить и экспериментировать. Не ищите обоснование, а просто попробуйте.
Прочитав пару статеек, наивно думал, что все права находятся в одном файле /etc/group, и что их можно редактировать как вручную в файле, так и специальные командами - без разницы. Это была самая грубая моя ошибка! А ещё не знал важные особенности настройки прав, влияющие на звук. Но вам повезло - я научу!
Кстати, полезно запомнить, как выглядят команды для добавления или удаления пользователя из группы (здесь опечатки нет, user и group стоят на правильных местах):
sudo usermod -a -G group user # для добавления пользователя user в группу group
sudo deluser user group # для удаления user из group
В итоге оказалось, что права пользователей хранятся одновременно в 2 файлах (второй - /etc/gshadow). Таким образом, иногда удаляя или добавляя их командами, я их слепо менял и в gshadow, а иногда редактируя вручную /etc/group, оставлял без изменений /etc/gshadow. Изредка получался прекрасный звук! А после экспериментов не мог его вернуть, хотя удачный /etc/group я сохранял, и права были на месте (как я считал)! Но не догадывался о /etc/ghadow, и не знал некоторые особенности.
Хотя в статьях и советуют, чтобы права пользователей в /etc/group и /etc/gshadow совпали, оказалось, для наилучшего звука они просто обязаны отличаться, иначе ничего не выйдет! Раньше я делал это вслепую и изредка получалось! Но не заметно для себя сбивал изящно настроенные права.
Пример хорошо звучащих прав - для наглядности (взял только значимые сущности). Но можете применить у себя (только не копируйте целиком всю строку, а то id пользователей в вашей системе будут другие, если вы устанавливали и настраивали систему не по моей инструкции).
Кстати, что удивительно, когда в группе несколько пользователей, то влияет порядок их записи. Например, "sudo:x:27:music,root" и "sudo:x:27:root,music" звучат по-разному!
Ну и как видим, права в этих двух системных файлах немного, но отличаются (в этом главная изюминка). В дальнейшем, восстанавливать права нужно в обоих файлах, чтобы повторить удачно настроенный звук.
А ещё, что странно, когда добавляешь пользователя в его же группу, то звук тоже меняется. Например, по умолчанию "root:x:0:" - группа root пустует. Но опытные линуксоиды знают, что пользователь всегда член своей группы. Однако, если добавить root в root, то после перезапуска плеера звук изменится!
Самое неприятная сложность в том, что на права влияют сдвиги, о которых я подробно написал здесь, поэтому после перезагрузки звук может оказаться не таким, какой вы его внезапно получили налету.
И конечно, надо помнить, что каждые отдельно взятые права влияют на все остальные. Например, если сейчас root в root звучит лучше, то после настройки других прав, может оказаться лучше без root в root.
Конечно, не все права одинаково сильно и хорошо влияют на звук, просто я много экспериментировал (порой даже не задумываясь о смысле этих прав), и получил хорошие результаты, которым захотел поделиться с вами!
5. Отключаем ненужные модули
Здесь на самом деле и просто, но и нет, потому что услышать разницу от изменения /etc/modprobe.d/blacklist.conf можно только после обновления ядра и перезагрузки:
sudo depmod -a
sudo update-initramfs -u
sudo reboot
Однако мне удалось найти модули, которые я обязательно отключаю - это SBS (smart battery status - пробовал искать информацию, но так и не понял, что он даёт, но без него звук резче в хорошем смысле и ярче) и video (с ним отключается плата hdmi, которая мне не нужна, а монитор всё равно работает, однако я бы советовал проявлять осторожность - может быть чёрный экран, я в этом случае подключался удалённо через ssh и всё исправлял).
Список модулей для экспериментов получить по команде lsmod. Здесь всё не так просто. Нельзя просто по очереди определить, какие модули лучше, а какие хуже. Они влияют друг на друга. Один и тот же модуль может вести себя по-разному, в зависимости от остальных. Запутаешься. Поэтому и остановился на двух, которые дают самую большую разницу или практическую пользу.
install video /bin/false
install sbs /bin/false
6. Ограничения системы ( security limits )
В конфиге /etc/security/limits.conf можно задавать ограничения для групп и пользователей по потреблению ресурсов (приоритеты реального времени, NICE приоритеты, ограничения памяти и прочее). Всё это влияет на звук. Я поделюсь своими рабочими вариантами, которые подбирал на слух. В системе много служебных пользователей, кроме root и вас, и все они поддаются настройке.
Однако логики здесь опять же никакой, и даже есть ошибки, без которых звук получается хуже. По логике улучшать не получается. Например, политика бывает мягкой (soft) и жёсткой (hard), а есть "-", которая по умолчанию означает жёсткую, при этом звучит не как одна из названных, а совершенно индивидуально. Вы можете придумать миллион своих (я не настаиваю, что эти варианты лучшие в мире, просто как пример - дерзайте!):
Вариант 1:
* - memlock 33802
* - rtprio 10
@audio - rtprio 95
@audio - memlock unlimited
@audio - nice -20
Вариант 2:
#* hard rtprio 33
* - memlock 32802
* - rtprio 25
#* - nice -20
@audio - rtprio 95
@audio - memlock unlimited
@audio - nice -20
Вариант 3:
* - priotity 90
* - rtprio 20
* - memlock 65536
* - nice -19
@audio - priotity 139
@audio - rtprio 95
@audio - memlock unlimited
@audio - nice -20
Вариант 4:
* hard rtprio 33
* - memlock 33802
* hard rtprio 10
* - nice -19
@audio - rtprio 95
@audio - memlock unlimited
@audio - nice -18
Вариант 5:
* - memlock 32762
* - rtprio 10
* - priority 89
avahi hard memlock unlimited
avahi - rtprio 3
#avahi - nice 17
@audio - rtprio 95
@audio hard memlock unlimited
@audio - nice -20
#@audio - priority 90
7. ALSA и субконфиги asound.conf + .asoundrc
Главный конфиг alsa (/usr/share/alsa/alsa.conf) у меня уникальный. Я много экспериментировал и отслушивал полученные экземпляры, один из них оказался самый выдающийся, который использую уже 2 года. Он получился совершенно случайно, когда копировал содержимое и вставлял мышкой, которая незаметно вставила содержимое буфера 2 раза. Я менял его первую половину, дорабатывал, а только потом узнал, что он "двоится". Но именно это и помогло мне получить тот звук, к которому я шёл долгие годы. Но у него есть минус - там внутри прописано устройство PCH (встраиваемая звуковая), поэтому с ЦАПами без исправлений он работать не будет, однако это легко поправить.
Субконфиги /etc/asound.conf (для системы) и /home/music/.asoundrc (для пользователя) тоже имеют много странностей. Сначала я пытался настраивать по логике, но потом просто стал делать это на слух!
Самое интересное, что эти конфиги читаются плеером MPD, даже когда они не указаны в файле alsa.conf, поэтому их никак нельзя игнорировать, несмотря что и без них всё прекрасно работает.
Неверняка, вы уже встречали эти строчки, которые советуют на форумах. Они задают, какое устройство используются по умолчанию для воспроизведения, а каким нужно управлять (например, оно первым будет открывать в alsamixer):
pcm.!default {
type hw
card 0
device 0
}
ctl.!default {
type hw
card 0
}
На самом деле, с этими субконфигами не всё так просто. Выбор устройства управления влияет на звук. И это не самый большой абсурд. Как вы уже поняли, усройства имеют числовые индексы, но имеют и имя. Вы можете указать 0, "0", PCH, "PCH" - это будет одно устройство, но звук совершенно разный! Кроме того, иногда получалось здорово, если в asound.conf указывал разные устройства воспроизведения и управления, а в .asoundrc менял их местами! Нет никакой логики!
Ещё больше меня удивило, когда я осознал спустя несколько лет, что права этих файлов сильно влияют на звук. А ещё, если этот файл обновить (с тем же содержимым), то звук тоже поменяется (станет светлее). Здесь много загадок, и я стараюсь больше не рыться глубоко. Однажды захотел сократить содержимое файлов, и написал в обоих файлах так:
pcm.!default { type hw card PCH}
ctl.!default { type hw card 0}
Звук мне очень понравился, но оказалось, звучит это совершенно по-другому, чем традиционная форма записи во множество строк. Видимо, дело в фигурной скобке. В одних местах система или плеер MPD кушает "PCH", а в других местах "PCH}". Истину я не знаю, одни догадки, но уже долго пользуюсь этой схемой, потому что корректная запись всегда звучит хуже.
8. Индексы карт alsa-base.conf
Для безупречного звука лучше позаботиться о том, чтобы ваше звуковое устройство имело индекс 0 (можно посмотреть в alsamixer). За это отвечает конфиг /etc/modprobe.d/alsa-base.conf. Моя встроенная звуковая карта имела индекс 1, а индекс 0 был у платы HDMI (даже если её отключить), а все внешние ЦАПы получают индекс 2 и выше (если их несколько). К сожалению, даже в файле alsa.conf есть параметры, где строго прописан индекс 0, даже если карта у вас с индексом 2, например в этом фрагменте:
defaults.hwdep.card 0
defaults.hwdep.device 0
defaults.timer.class 2
defaults.timer.sclass 0
defaults.timer.card 0
defaults.timer.device 0
defaults.timer.subdevice 0
Согласитесь, странно, если ЦАП с индексом 2, а timer берётся от платы HDMI (или от вообще не существующей в системе карты). Я уверен, что кроме alsa.conf, в Linux много-много мелких моментов похожего характера, которые могут стать препятствием на пути к совершенству.
Чтобы встройка имела index 0, я добавил следующие строки и удалил некоторые ненужные, но с ЦАПами этот файл может работать не корректно:
options snd-hda-intel index=0 id=PCH
options snd-hda-intel index=1 id=HDMI
Ставьте лайки и читайте другие статьи о звуке на моём канале (не забудьте подписаться)