[pulseaudio-discuss] Per (sink input, sink) volume control / routing
georg at chini.tk
Mon Feb 19 16:11:16 UTC 2018
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
> compensated) latency.
> - 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!
> Andreas Hartmetz
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
More information about the pulseaudio-discuss