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
