[pulseaudio-discuss] Sending audio from source to multiple sinks dynamically

[Timothy J Massey]

pulseaudio-discuss-bounces at mail.0pointer.de wrote on 06/17/2009 12:34:25 
PM:

> 'Twas brillig, and Timothy J Massey at 17/06/09 17:54 did gyre and 
gimble:
> > pulseaudio-discuss-bounces at mail.0pointer.de wrote on 06/17/2009 
05:35:59 
> >> If someone would code such a module the zone-mixer setup would be 
very
> >> easy. Probably something like having a null sink for every MPD and 
the
> >> connecting the null sink monitor sources to any zone sink. This would
> >> offer the most flexibility and hopefully also without any delay
> >> between the different zones.
> > 
> > I don't know that what is needed is an entirely new module.  I am 
assuming 
> > that I am correct that PA allows a source to only connect to a single 
> > sink:  no one has corrected this assumption (yet).
> 
> I think you mean a "SinkInput" rather than a "source" above. The term 
> "Source" is used in pulseaudio and means something different :) I 
> presume by "source" above, you mean e.g. an audio producing application? 

> If so, this is indeed a "SinkInput".

Yes, that is correct.  I assumed that such a device would be considered a 
source (just like, say, a microphone input), but I can see now how that 
would not be the case.

> > Of course, the purpose of module-combine is to get around this 
limitation, 
> > by creating a single virtual sink that then pushes the data out to 
> > multiple slave sinks, which is *exactly* what I want to do.  The only 
> > problem is FWICT the list of slaves have to be hard-coded in advance. 
I 
> > would like some way of dynamically altering the list of slaves, 
without 
> > interrupting playback of the uninvolved slaves.  That is the *only* 
thing 
> > that is missing!  :)
> 
> No, once module combine is created it cannot be altered. It should in 
> theory be possible for it to be improved so it provides a protocol 
> extension that allows such interaction.

That's well beyond what I want to do.

> To be honest tho', I think it 
> would make more sense to create a new combined module with the correct 
> slaves, then move the sinkinputs attached to the old combine module, 
> across to this new one, and then remove the old combine completely.
> 
> Chances are tho' that this process would cause some kind of blip in the 
> audio. It wont be much of a blip tho' (if it even exists).

OK.  I get this.  Instead of pre-generating all of the possible 
permutations, just create the one that is needed, given what the users 
have selected.  The problem I have with this was that I don't immediately 
see a way of querying PA to find out what sinks are currently combined 
into a virtual sink.  My goal was a very simple stateless design, and this 
will require a central daemon responsible for handling this, to e.g. avoid 
races with other zones.  But I do understand what you're saying.

> I think this approach would actually be easier than creating a protocol 
> extension. You'd probably still want some sort of module (or external 
> app - but a module is nicer IMO) to "watch" for sinks coming and going 
> and a definition of combined sinks you want so it can create these lists 

> as an when they are possible.

And handle what sinks need to switch to what sink-inputs (not sources!  :) 
 ) and when, etc.

> > Is there a way to communicate with modules once they're loaded?  Such 
as 
> > from the PA command line?
> 
> Not really. A module would have to extend the protocol to do this kind 
> of stuff.

I'm surprised by that:  that there isn't a way to pass them a message from 
the PA command line...  But so be it:  protocol extensions are well beyond 
what I'm looking for.

> Your mpd's should just "play" normally, and you can then move the 
> streams (sinkinputs) around as you need. there is no need to push them 
> into a pipe and then connect that pipe's source to a sink. That's just 
> overcomplicating things :)

You are correct.  Using FIFO's was a way of handling switching sink-inputs 
around outside of PA, to get around the fact that module-combine can't do 
it.

> All you need to do is define several named zones which are implemented 
> as module-combine sinks. This definition (be it XML, plain text etc.) 
> should be managed by a "combine-watchdog" module which is able to 
> teardown and rebuild the combined sinks when it is reconfigured (and/or 
> the sinks it combines come and go) without relocating the attached sink 
> inputs.

Exactly.  I understand.

> It probably wouldn't take too much to write such a module and avoids 
> complicated timing problems of connecting sources to sinks.

It's too bad that modules can't accept messages from e.g. the PA command 
line.  Because module-combine already does all of this.  It just can't 
change its list of slaves dynamically...



Another way of doing this was given to me by Matthew Patterson.  He used 
module-combine to create a single virtual sink for each sink-input (i.e. 
each instance of MPD), and included *each* physical sink in that virtual 
sink.  Then, to control what was actually playing through each physical 
sink, he would simply mute all sink-inputs for that sink, and unmute the 
one that the user selected.  The nice thing is that this should not glitch 
the audio for any sink that's not being changed.

That's better than creating all of the possible permutations of virtual 
sinks, and doesn't require a stateful daemon.  Given that, without heavy 
lifting, module-combine can't be altered dynamically, I think that this 
will work for now.

Thank you all very much for your assistance with this.  I appreciate your 
help.

Tim Massey