WirePlumber: продвинутые настройки wireplumber.conf
Если после загрузки выбирается не тот выход, HDMI встроенной карты торчит в списке лишней строкой, а внешний ЦАП засыпает через минуту простоя, причина почти всегда в конфиге WirePlumber. В версии 0.5 настройки разложены по десяткам фрагментов, и без понимания иерархии непонятно, какой из них всё решает. Разберу, где физически лежат файлы, как устроено правило для карты или узла и как отключить авто-поведение, которое мешает жить.
Где лежат настройки и в каком порядке их читают?
WirePlumber читает три каталога: /usr/share/wireplumber/ с фабричными файлами пакета, /etc/wireplumber/ для общесистемных правок и ~/.config/wireplumber/ для личных. Сначала загружается главный файл /usr/share/wireplumber/wireplumber.conf, затем подхватываются фрагменты из wireplumber.conf.d/ в каждом каталоге, в алфавитном порядке.
Два момента стоит запомнить сразу. Первый: файл с тем же именем в каталоге с более высоким приоритетом полностью заменяет системный, а не дополняет его. Второй: в 0.5 из поставки в wireplumber.conf.d/ лежит только alsa-vm.conf, а логика монитора ALSA живёт в Lua-скриптах /usr/share/wireplumber/scripts/monitors/alsa.lua. Файлов 50-alsa-config.conf и 51-alsa-acp.conf из версии 0.4 больше нет, и если искать правки в них, поиск заведёт в тупик.
pacman -Qo /usr/share/wireplumber/wireplumber.conf
ls -l /usr/share/wireplumber/wireplumber.conf.d/ /etc/wireplumber/
ls /usr/share/doc/wireplumber/examples/wireplumber.conf.d/
Готовые рабочие примеры лежат в последнем каталоге: alsa.conf, device.conf, profile.conf, stream.conf, log.conf. Скопируй нужный в ~/.config/wireplumber/wireplumber.conf.d/ под своим именем и правь на месте.
Как устроено правило monitor.alsa.rules?
Конфиг написан в SPA-JSON: ключи верхнего уровня — свойства контекста PipeWire, поэтому всё живёт в именованных пространствах monitor.alsa, monitor.bluez, monitor.v4l2, monitor.libcamera, плюс секции wireplumber.settings и wireplumber.profiles. Правило состоит из двух половин: matches с условиями отбора и actions с тем, что сделать.
# ~/.config/wireplumber/wireplumber.conf.d/50-custom.conf
monitor.alsa.rules = [
{
matches = [
{ node.name = "alsa_output.usb-Generic_USB_Audio-00.analog-stereo" }
]
actions = {
update-props = {
node.nick = "USB DAC"
node.priority.session = 2000
}
}
}
]
Условия и свойства берутся из одного пространства: для карты это device.*, для отдельного выхода или входа — node.*. Переименование узла и приоритет в примере из этого раздела меняют вид в списке и выбор по умолчанию, но не трогают остальные карты.
Значение с ведущей ~ читается как регулярное выражение, так что одним правилом ловятся все устройства сразу. update-props перезаписывает свойства, а insert-props добавляет их, ничего не затирая, — второй вариант удобен, когда свойство уже задано в системном фрагменте.
Как отдать приоритет своему выходу и не забыть его?
Дефолтный выход выбирается по priority.session, и у большинства узлов там 1000. Подняв значение для нужного, получаешь его в списке первым. Но есть подвох: пока включено запоминание прошлого выбора, при старте сессии и при отключении устройства приоритеты почти не учитываются, и система возвращает то, что было выбрано в прошлый раз. Лечится отдельной настройкой.
wireplumber.settings = {
node.restore-default-targets = false
}
Убрать из памяти уже записанные значения можно полным сбросом состояния: сначала остановить сервис, удалить ~/.local/state/wireplumber, затем запустить обратно. Сброс стоит делать осознанно — вместе с ним улетят сохранённые громкости потоков. Подробнее про внешние ЦАП и их подключение — в статье про USB-карту как внешний ЦАП.
Почему приоритет не срабатывает с первого раза
Проверь вывод wpctl status: у узла с поднятым приоритетом в скобках должен стоять ненулевой vol, а сам он — выше в списке. Если приоритет в правиле выставлен, а в статусе значения прежние, значит правило не совпало: обычно из-за device.id в matches или опечатки в node.name. Второй частый случай — в каталоге лежит файл с расширением .txt или без .conf, и он молча игнорируется.
Как убрать лишнее устройство и задать профиль карты?
Отключается карта и узел по-разному: device.disabled = true прячет карту целиком вместе со всеми её выходами, а node.disabled = true убирает только конкретный выход, оставляя остальные рабочими. Для встроенного HDMI почти всегда нужен второй вариант с отбором по node.nick.
Профиль задаётся через ACP-свойство alsa.card.profile. Имя профиля берётся не из головы, а из конфигов UCM, которые перечисляют секции для конкретной подписи карты.
monitor.alsa.rules = [
{
matches = [
{ device.name = "alsa_card.pci-0000_0c_00.4" }
]
actions = {
update-props = {
alsa.card.profile = "iec958"
}
}
}
]
ls /usr/share/alsa/ucm2/conf.d/
grep -m5 '^Section' /usr/share/alsa/ucm2/conf.d/Signature-*/iec958.conf
Логику выбора профиля и ручное переключение я разбирал в статье про переключение аудиопрофилей в WirePlumber — с правилами становится понятно, что именно перебивает автоперебор.
Как отключить авто-приостановку и авто-подключение?
Узлы усыпляются при простое, потоки подключаются к первому подходящему выходу, а сессии пользователя отслеживаются через logind. Все три вещи включаются фрагментом, и каждая отключается своим ключом.
monitor.alsa.rules = [
{
matches = [
{ node.name = "~alsa_output.usb-.*" }
]
actions = {
update-props = {
node.suspend_on_idle = false
}
}
}
{
matches = [
{ node.name = "~alsa_output.pci-.*.iec958-stereo" }
]
actions = {
update-props = {
node.autoconnect = false
}
}
}
]
node.suspend_on_idle = false снимает усыпление по простою, а в 0.4 для этой же задачи клали node.suspend_timeout_ms = 0 — ключ устарел и в новых версиях не читается. node.autoconnect = false пригождается, когда выход надо контролировать вручную: JACK-сессии, мастер-микшер или собственный роутинг. Плюс отключение слежения за сессией, которое в 0.5 живёт в профиле main:
wireplumber.profiles = {
main = {
monitor.bluez.seat-monitoring = disabled
}
}
В 0.4 для того же писалось support.logind = false, в 0.5 ключ устарел. Если не нужно сохранять громкости и прошлый выбор вообще, добавь wireplumber.persist = false.
Почему правка ничего не меняет и как это отлаживать?
Фрагмент без расширения .conf не читается, файл в неправильном каталоге игнорируется, а после правки сервис не перечитывает состояние сам. Порядок простой: перезапустить, посмотреть лог, найти идентификатор, вытащить свойства.
systemctl --user restart wireplumber
journalctl --user -u wireplumber -b -f
wpctl status
wpctl inspect 48
pw-top
Ошибка парсинга SPA-JSON видна в логе сразу после рестарта — чаще всего виновата лишняя запятая или забытые кавычки вокруг имени свойства. wpctl inspect показывает все свойства объекта целиком, оттуда берутся точные значения для matches. wpexec применяет фрагмент к уже запущенному экземпляру, но после рестарта настройки всё равно подхватятся из файла.
Подробные логи включаются отдельным фрагментом: в поставке уже есть готовый пример с настройкой уровня логов, копируешь его к себе, перезапускаешь сервис и читаешь вывод.
cp /usr/share/doc/wireplumber/examples/wireplumber.conf.d/log.conf \
~/.config/wireplumber/wireplumber.conf.d/90-log.conf
systemctl --user restart wireplumber
journalctl --user -u wireplumber -b -f
Порядок чтения работает и в пользу пользователя: личные фрагменты подключаются последними, поэтому update-props в них перебивает значения из системных файлов. Если свойство не меняется, сначала проверь, не задано ли оно там же в более позднем по алфавиту фрагменте, а потом уже переходи к отладке.
Частые вопросы
Нужно ли править /usr/share/wireplumber/ напрямую?
Нет, pacman перезапишет файл при следующем обновлении пакета. Правь в /etc/wireplumber/ для общесистемных настроек или в ~/.config/wireplumber/ для личных — второй вариант приятнее тем, что переживает обновления и легко удаляется.
Как сбросить запомненные устройства и громкости?
systemctl --user stop wireplumber
rm -r ~/.local/state/wireplumber
systemctl --user start wireplumber
Каталог восстановится пустым, и WirePlumber запишет в него состояние заново. Перед удалением стоит закрыть плеер, иначе громкость активных потоков перезапишет файл обратно.
Чем правило карты отличается от правила узла?
Отбором и набором свойств. В matches для карты пишют device.name, для узла — node.name или node.nick, а в actions для карты доступны device.*, для узла — node.*. Ошибка в этом месте выглядит как «правило есть, а ничего не изменилось».
Как найти стабильный идентификатор карты?
wpctl status даёт список, wpctl inspect с номером из этого списка — все свойства, включая device.name и node.name. Именно их и стоит класть в matches: device.id пересоздаётся между сессиями и ломает правило после перезагрузки.
Можно ли переключить вывод без конфига вообще?
Да, номер из wpctl status подходит как аргумент команды, а звёздочка в выводе помечает текущий дефолт.
wpctl status
wpctl set-default 48
Так удобно проверять приоритеты вживую, но выбор не переживает перезапуск сессии, пока включено запоминание, и после рестарта всё вернётся к тому, что лежит в состоянии. Для постоянства нужен либо сброс node.restore-default-targets, либо правило с приоритетом.
Полезные ресурсы
- ArchWiki: WirePlumber — каталог конфигурации, примеры правил, сброс состояния.
- ArchWiki: PipeWire — свойства узлов, маршруты, одновременный вывод на несколько устройств.
- PipeWire не запускается: конфликт с PulseAudio — когда мешает второй менеджер сессии.
- Нет звука после установки WirePlumber — проверка сервисов и маршрутизации до настройки правил.
Заключение
В WirePlumber 0.5 настройка живёт в правилах с matches и actions, а приоритеты работают только вместе с отключённым запоминанием выбора. Правь один фрагмент в ~/.config/wireplumber/wireplumber.conf.d/, перезапускай сервис и проверяй результат через wpctl inspect — этого хватает для почти всех задач с приоритетами, отключения лишних устройств и авто-поведения.
Не получилось? Поможем настроить
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии