pulseaudio, config hell. Как в этом всём разобарться?

Чем тебя не устроила документация? Идёшь в список модулей, ищешь module-sink-combine, читаешь доку по аргументам, через pactl его подгружаешь с нужными аргументами и перекидываешь туда всё что нужно.

Где ты нащёл config hell — тем более не понятно. У пульсы ровно один конфиг, который представляет собой «скрипт» из команд а-ля pacmd, который выполняется при запуске.

Чем тебя не устроила документация?

Вот этим:

module-combine-sink

Since 1.0 (prior to 1.0 this same module was available with name «module-combine»). This combines two or more sinks into one. A new virtual sink is allocated. All data written to it is forwarded to all connected sinks. In equidistant intervals the sample rates of the output sinks is recalculated: i.e. even when the sinks' crystals deviate (which is normally the case) output appears synchronously to the human ear. The resampling required for this may be very CPU intensive.

    sink_name
        The name for the combined sink. (defaults to «combined»)
    sink_properties
        Since 0.9.15. Property list for the combined sink.
    slaves
        Name of sinks to link into the combined think, separated by commas.
    adjust_time
        Time in seconds when to readjust the sample rate of all sinks. Zero means that readjustment should be disabled. Default: 10.
    resample_method
        Resampling algorithm to use when adjusting to the sample rate differences between the slave sinks. TODO: Create a page, and add a link to it here, that explains all the different resamplers that are available. While waiting for that to happen, users can refer to man pulse-daemon.conf, more specifically the resample-method option documentation.
    format, rate, channels, channel_map
        Parameters for the combined sink. See the Device Drivers section at the top of this page for details.

Модуль-то я загружу, а дальше-то что делать? Где конкретно в конфигах надо потом менять sink.voice (или чего там я захочу) на вот этот новый sink.combined?

А ещё в конфиге есть уже

### Sink for playing ringtones to both IHF and BT/HSP
# The set value for 'adjust_time' is a workaround in two ways. 1) The possible sample rate adjustment seems to cause some long gaps in ringtone, so it needs to be disabled. The root cause is not known. 2) The documented behavior of value 0 is not valid as it causes constant readjustments instead of disabling it.
load-module module-combine sink_name=sink.hw0andhw1 slaves=sink.hw0,sink.hw1 slave_amps=0,-2 resample_method=trivial adjust_time=300 bt_alsa_device_desc=«ALSA PCM on hw:dfl61wl1273 () via DMA»

Не поссорятся ли эти 2 combined из-за одного используемого в обеих sink.hw0 например?

Модуль-то я загружу, а дальше-то что делать? Где конкретно в конфигах надо потом менять sink.voice (или чего там я захочу) на вот этот новый sink.combined?

Нигде. Сделать ему set-default-sink (если предыдущий был дефолтом) и переместить все имеющиеся sink-input'ы с sink.voice на sink.combined. Ванильная пульса очень просто устроена.

Не поссорятся ли эти 2 combined из-за одного используемого в обеих sink.hw0 например?

Не должны.

IHF and BT/HSP

А если у тебя Meego/Mer/Sailfish и ты не можешь понять, что вообще происходит — то я тоже не могу понять. Они наворотили поверх пульсы адскую сместь кастомных плагинов и недокументированной автомагии, в которой разобраться так и не получилось.

переместить все имеющиеся sink-input'ы с sink.voice на sink.combined. Ванильная пульса очень просто устроена.

Как получить список этих sink-input'ов?

Далее - как в этой долбаной пульсе найти модуль, который просто стримит юникастом по UDP на указанный порт и адрес, например? RTP там оказывается _только_ мультикастный, *-tcp требуют уже работающего сервера на той стороне, иначе оно просто не принимает данные от проигрывателя, например.

Вроде как у sink'ов есть какие-то .monitor и т.п., т.е. можно сотворить null-sink, чтобы поток не задерживало отсутствие коннекта, и использовать какой-то sinkname.monitor для указания октуда модулю брать поток. Но почему-то у *-tcp модулей нет ничего про параметр где указывается откуда брать поток, они тупо создают sink который тупит без сервера. В общем, документация вообще не даёт ответа на вопрос что это и как использовать.

Кроме того, попытался найти в доках информацию про .monitor у sink. Что это вообще, и как работает. Может мне вообще можно просто с sink.voice.monitor отправить поток куда-нибудь, так ведь нет в доках ничего про .monitor ( и, возможно, другие .фигзнаетчто ), только убогие примеры, где этот .monitor используется.

А если у тебя Meego/Mer/Sailfish и ты не можешь понять, что вообще происходит — то я тоже не могу понять. Они наворотили поверх пульсы адскую сместь кастомных плагинов и недокументированной автомагии, в которой разобраться так и не получилось.

У меня meego и там совершенно ванильная пульса, из проприетарных модулей там только

module-nokia-algorithm-aep              Nokia proprietary aep algorithm module
module-nokia-algorithm-agc              Nokia proprietary agc algorithm module
module-nokia-algorithm-drc              Nokia proprietary drc algorithm module
module-nokia-algorithm-eq               Nokia proprietary eq algorithm module
module-nokia-algorithm-ramp             Nokia proprietary ramp algorithm module
module-nokia-algorithm-remix            Nokia proprietary remix algorithm module
module-nokia-algorithm-rmc              Nokia proprietary rmc algorithm module
module-nokia-algorithm-xprot            Nokia proprietary xprot algorithm module
module-nokia-eci-parameters             Nokia proprietary ECI parameters module

которые всего лишь реализуют аппаратную обработку звука на проприетарном железе и к коммутации потоков никак не относятся.

Всё остальное - опенсорсное и в общем-то тоже не относящееся к коммутации и стримингу.

Как получить список этих sink-input'ов?

pactl list short sink-input

Далее - как в этой долбаной пульсе найти модуль

https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules

который просто стримит юникастом по UDP на указанный порт и адрес, например?

Такого нет.

*-tcp требуют уже работающего сервера на той стороне, иначе оно просто не принимает данные от проигрывателя, например.

А ты как хотел?

Но почему-то у *-tcp модулей нет ничего про параметр где указывается откуда брать поток, они тупо создают sink который тупит без сервера.

Потому что пульса работает по-другому. Модули *-sink-*, внезапно, создают sink, в который можно направить один или более sink-input'ов.

Кроме того, попытался найти в доках информацию про .monitor у sink. Что это вообще, и как работает.

А что должно быть в доках? Это просто source, который дублирует соответствующий sink.

Может мне вообще можно просто с sink.voice.monitor отправить поток куда-нибудь

Конечно, можно. pacat -r -d sink.voice.monitor | nc ....

У меня meego и там совершенно ванильная пульса

Значит, в meego этого дерьма нет и тебе повезло.

А что должно быть в доках? Это просто source, который дублирует соответствующий sink.

Ну хотя бы что вот есть sink, и у каждого sink есть sinkname.monitor который можно использовать как source.

Конечно, можно. pacat -r -d sink.voice.monitor | nc ....

В итоге так и сделал. Работает без проблем.

В общем, оказалось всё элементарно, правда без пульсовых настроек, да и вообще.

В общем, у каждого sink'а есть монитор - source с именем sink_name.monitor. Ну и с него можно тупо поток например записывать в файл, или там отправлять в трубу.

parec --raw --volume 65536 -d sink.voice.monitor | netcat -u 192.168.253.20 4172

Делов-то. И что самое смешное - в документации про это ничего. :)

А ты как хотел?

Ну как бы аудио - это всё же потоки, которые не должны ни при каких условиях останавливаться. А тут бред получается - кнопка play нажата, а проигрыватель висит. В частности для *-tcp ожидал что оно будет поток принимать всегда, если куда-то подключился - то поток принимаемый полился в сеть, отключился - опять поток в /dev/null уходит, но не останавливается. Ну это как минимум логично бы было.

Отсутствие в пульсе сетевых стримеров в UDP конечно удивило. :)