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

[Andreas Hartmetz]

Am Mittwoch, 21. Februar 2018, 11:24:17 CET schrieb Tanu Kaskinen:
> On Mon, 2018-02-19 at 17:21 +0100, Andreas Hartmetz wrote:
> > Am Montag, 19. Februar 2018, 17:05:27 CET schrieben Sie:
> > > On 02/19/2018 06:46 PM, 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).
> > > 
> > > Volume for each sink-input can configured separately:
> > Thanks, but...
> > 
> > Note sure who is misunderstanding who.
> > I did not mean per sink-input, I meant per *tuple* (sink input,
> > sink). The volume is a property of the connection between sink
> > input and sink. If in your example, the loopback represents the
> > application stream, you misunderstood me. If in your example, the
> > loopback is somehow specific to the connection between sink input
> > and sink, sitting in the middle of a more complicated routing
> > graph, I misunderstood you.
> You seem to be talking to Georg, even though your reply went to
> Raman... Anyway, you seem to have misunderstood Georg. I think Georg's
> idea was very similar to your idea of loading a module-combine-sink
> instance for every application stream. Georg's idea was to replace
> the combine sink with a null sink, and to use module-loopback
> instances to forward the audio from the stream's null sink to the
> desired hardware sinks.
> 
Thanks for setting me straight and the summary. Thanks to Georg, too. 
What apparently happened is that I sent my first message seconds or 
minutes after signing up for the list and the first messages (including 
my own) did not reach me. I checked the online archive now.

> The benefit of Georg's approach is that you might get away without
> modifying pulseaudio. One drawback is that the null sink won't report
> the real latency to the application, but if the latency is low enough,
> maybe that doesn't matter.
> 
The latency will not be a problem for now. There will be strict (and yet 
unknown to me) latency requirements for the final product. So this may 
need revisiting, but for now, to get something working and continue 
development, this is a fine solution!
(Also I personally hate latency, and if the platform is ever going to 
run games, <= 15 ms would be nice. This is not the time to get bogged 
down by that, though.)

> Are you in control of what version of pulseaudio will be used? Can you
> use a patched version? If you end up needing a custom module, you
> will have to be in control of the pulseaudio version, because modules
> aren't compatible with different daemon versions.

Yes, the version will be under control because the OS images will be 
either custom or customized. We agreed to pick and stay at, until and 
unless a decision is made to upgrade, 11.1 because, well, latest version 
right now.

Thanks,
Andreas