[pulseaudio-discuss] Per (sink input, sink) volume control / routing

[Georg Chini]

On 19.02.2018 16:46, Andreas Hartmetz wrote:
> Hello!
>
> 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.
>
> So:
> - 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
hardware).

Regards
              Georg