[pulseaudio-discuss] Mixing audio from multiple sink-inputs to multiple sinks dynamically

[Tanu Kaskinen]

On Tue, 2016-04-05 at 15:13 +0200, Lode Cools wrote:
> Hi,
> 
> This topic has been touched before, but I did not find a conclusion:
> 
> How does one create an end-user solution where it is possible to mix
> (select & combine) multiple sink-inputs into multiple sinks and then change
> this 'mix' selection dynamically (preferably glitch-free)?  The changes
> would be performed using the D-Bus API (or any other API if that is
> required).

Only the C API is "supported". The D-Bus API can be used too, but if
you have problems with it, you're on your own. The D-Bus API doesn't
have any stability guarantees, but in practice it's pretty stable, like
dead things tend to be.

> A simple example is: I am playing sink-input SI1 on combine-sink C1 which
> uses physical sink S1 as its slave.  Now I also want to play sink-input SI1
> on physical sink S2.
> 
> For the moment, I know 2 ways to accomplish this dynamically:
> 
> 1) 'create new combines' - approach
>    * I create a new combine-sink C2 which uses both sink S1 and sink S2 as
> its slaves.  Then I move the sink input SI1 from old combine-sink C1 to new
> combine-sink C2.  Afterwards, I delete the old combine-sink C1.
>    * Disadvantages:
>       ** not glitch-free (especially for listeners of sink S1 who do not
> care about S2)
> 
> 2) 'mute the unused links' - approach
>    * I create from the beginning a 'full mesh': C1 uses both sink S1 and
> sink S2 as its slaves.  'playing a sink-input on a sink' then just
> translates to 'unmuting the sink-input from the combine-sink on the actual
> sink'
>    * Disadvantages:
>       ** when dealing with a lot of sink-inputs and sinks, the amount of
> 'links' is huge.  If a muted input is also increasing the resample load
> (Can anyone confirm this statement?), this might be a resource-consuming
> solution.

Yes, muted streams are resampled too.

>       ** all sinks need to be known upfront
> 
> 
> Ideally, there would be a solution where you could change the slaves of a
> combine-sink dynamically.  But, afaik, this does not exist and is not
> planned either.

It may not be planned, but patches implementing dynamic combine sink
slave management would definitely be welcome.

module-combine-sink already supports dynamic slave changes internally,
because it has a mode where it plays to all sinks in the system, and
that requires automatically adding and removing outputs as sinks come
and go.

> So the question is:  Are solution 1 and 2 really the only solutions for my
> problem?

I don't have any other solutions, apart from adding an API for the
combine sink slave management.

> Which one of the solutions would you favor over the other?

They have different tradeoffs, so which one is better depends on the
situation.

-- 
Tanu