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
