On 19.02.2018 16:46, Andreas Hartmetz wrote:
I am currently developing an audio system for an automotive customer,
based on PulseAudio where PulseAudio is applicable. It is part of the
requirements that the volume of every input channel (sink input) to
every output channel (sink) can be configured separately. There are
good reasons for this, for example there can be two backseat info-
tainment "terminals" which could send their audio to a headphone for
each, or to the speakers in the whole car. The user-exposed volume
controls will of course present a simplified vew, but for factory
configuration, the described control is needed, and volume levels are
expected to change at runtime in response to some external events.
The problem is that PulseAudio does not support that. It could almost
be "hacked" by using one module-combine-sink for every sink input,
which at least allows sending a stream to an arbitrary collection of
sinks. But it does not support volume control at all.
- Is there a way that I didn't think of to piece together the
desired volume control using existing modules and/or other
configuration? I don't want to resort to anything really weird
like creating lots of "loopback" devices using local sockets or
something like that (also for latency reasons), and running
multiple server instances also won't do it due to PA requiring to
open devices exclusively. Also, any hacky solution is not allowed
to significantly increase (or worse, hide from PA so it can't be
- If not, what do you think would be the best way to do it? I'm
thinking of a potential "module-crossbar" that I would need to
write, which allows matrix-style (n, m) volume control, i.e.
set_volume(sink_input_index, sink_index, volume).
Thanks in advance!
The problem is, that a sink-input is always connected only
to exactly one sink. Changing this would require major rework
of PA. So your crossbar module could only be a more elaborate
version of the combine-sink.
What you can do without changing code is to let the sink-input
play to a null-sink and then use multiple module-loopback
instances from the null-sink monitor source to your destination
sinks. The loopbacks then each have a volume control. It should
not introduce too much latency, the monitor source immediately
spits out what the sink input delivers and module-loopback can
safely run at 50ms latency (or even lower, depending on your
pulseaudio-discuss mailing list