делит ее на два девайса

А в чем разница между ними?

Прописать в asoundrc клонирование сигнала на 2 девайса, а подавать в PA сигнал на виртуальный девайс - не вариант?

А разница между ними в том, что если выводить звук на первый девайс, то ни альса, ни пульс ругаться не будут, но в наушниках будет тишина. ХЗ, что там корейцы наворотили.

Как реализовать второе ваше предложение - честно говоря, не знаю. Если не сложно, чуть подробнее опишите, плз.

http://linuxoid.in/Конфиг:asoundrc,_параллельный_вывод_звука_на_несколько_вых...

По такому принципу, а PA скармливать уже allcard. Но вообще должен быть какой-то более правильный выход - это должно делаться на уровне самого PA.

Спасибо, гляну, чтоб хоть представлять. На уровне самого PA пока только нашел вот это: load-module module-alsa-sink device=hw:1,1

тогда в устройствах вывода появляется нужный мне девайс, и все вроде бы замечательно, и вообще можно указанную команду увязать с udev'ом, написав соответствующее правило. Но вот незадача, в бубунте 14.04, например, пульс после этого может умереть с рандомной вероятностью. А в федоре (просто пробовал лайв-усб из того, что было) пульс оказался сильнее, но вырубился ЦАП, так что пришлось его по питанию отключать и включать заново.

Я вообще внешний ЦАП использую исключительно для музыки, а встроенную карту для всего остального. В плеере указан монопольный доступ к интерфейсу ЦАПа. Проблемы нет :)

Копать в сторону /usr/share/pulseaudio/alsa-mixer/profile-sets, PulseAudio Profiles, ну и PulseAudio Examples в арчвики.

нашел вот это: load-module module-alsa-sink device=hw:1,1

Так тоже можно и должно работать, но да, plug'n'play не сделаешь: из udev до пульсы ты вряд ли достучишься, потому что она запущена от имени пользователя и pacmd общается с ней по сессионной D-Bus шине.

А вот если падает пульс или умирает ЦАП — нужно копать в сторону драйвера...

1) почему бы не юзать встроенную в систему (в DE, если быть точным) переключение звука? вот так, к примеру: http://i.imgur.com/YQpUH4Y.png
2) поставь себе pavucontrol

З.Ы. Может, я не до конца понял суть вопроса

укажи в конфиге пульсы дефолтным синком hw1.1
я так для nvidia HDMI делад

udevd вроде и для пользователей умеет скрипты пускать? иначе как в гнум сделали 3.16, что при втыкании флешек звуковое уведомление, как в виндавс

udevd вроде и для пользователей умеет скрипты пускать?

Ни разу.

при втыкании флешек звуковое уведомление

Скорее всего, через шинное API udisks2.

для пользователей умеет скрипты пускать

Более того — этого, скорее всего, недостаточно. Я не зря там написал «общаются по сессионной шине».

когда воткнул мышь, вебку - то же звук

Тогда, возможно, они используют API udev и слушают его события. Так или иначе, ни о каком запуске процессов в контексте пользовательской сессии из правил udev речи не может идти.

так можно и по api udev сделать то, что хочет ТС

Можно. Но об этом в треде речи вообще не шло. Ты пытаешься мне доказать, что можно и из самого udev запускать процессы от пользователя.

Ура! Получилось!

Спасибо тебе, intelfx, за наводку на профайлы пульсы! Почитал, завел. Теперь самый настоящий PnP у меня.

Итак, что нужно сделать:

1. Создаем новое правило /etc/udev/rules.d/91-audinst.rules:

ATTR{id}=="HUDmx2", ACTION=="change", ENV{PULSE_PROFILE_SET}="audinst-mx2.conf"

2. Создаем новый профайл /usr/share/pulseaudio/alsa-mixer/profile-sets/audinst-mx2.conf:

[General]
auto-profiles = yes

[Mapping analog-stereo]
device-strings = front:%f hw:%f,1,0
channel-map = left,right
paths-output = analog-output
priority = 10

Вообще, я взял за основу дефолтный профайл и удалил из него все лишнее. Главное отличие - это строка device-strings.

3. В виде бонуса, если нужно, чтоб пульс автоматом начинал использовать подключенный ЦАП, добавляем в /etc/pulse/default.pa строку:

load-module module-switch-on-connect

4. Явно просим udev освежить правила sudo udevadm control --reload-rules и рестартим пульсу pulseaudio -k. Ну или просто делаем ребут.

Проверялось все на Убунту 14.04 и Дебиан стэйбл. Возможно, в других дистрибутивах профайлы пульсы могут лежать по другому пути. Линейный выход данного ЦАПа, а также оптический пока не проверял, но думаю, что особых проблем не будет (максимум, профиль подредактировать).

я не пытаюсь доказать, просто интересно, как гнумеры это сделали
наверное можно сделать и то, что хочет ТС

Улучшенный вариант

Все не доходили руки, оставлю исправленный вариант профайла (для красоты) и правила udev (первая версия некорректно работала, если девайс был воткнут в комп при загрузке).

1. /etc/udev/rules.d/91-audinst.rules:

SUBSYSTEM!="sound", GOTO="pulseaudio_end"
ACTION!="change", GOTO="pulseaudio_end"
KERNEL!="card*", GOTO="pulseaudio_end"

ATTR{id}=="HUDmx2", ACTION=="change", ENV{PULSE_PROFILE_SET}="audinst-mx2.conf"

LABEL="pulseaudio_end"

2. /usr/share/pulseaudio/alsa-mixer/profile-sets/audinst-mx2.conf:

[General]
auto-profiles = no

[Mapping analog-stereo-device1-output]
description = Analog Stereo
device-strings = hw:%f,1,0
channel-map = left,right
direction = output

[Profile output:analog-stereo-device1]
description = Analog Stereo Output
output-mappings = analog-stereo-device1-output
priority = 10
skip-probe = yes

Эээ, а что изменилось? При ACTION=="add" тоже нужно выполнять правило.

Я бы так написал, без всяких goto в конец (они нужны исключительно как костыль на тот случай, когда у тебя много правил имеют общую часть, потому что в udev нет условных блоков):

SUBSYSTEM=="sound", ACTION!="remove", ATTR{id}=="HUDmx2", ENV{PULSE_PROFILE_SET}="audinst-mx2.conf"