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


pulseaudio-discuss mailing list

Reply via email to