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. 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. 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. -- Tanu https://liberapay.com/tanuk https://www.patreon.com/tanuk
