[pulseaudio-discuss] Sending audio from source to multiple sinks dynamically
gmane at colin.guthr.ie
Wed Jun 17 09:34:25 PDT 2009
'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".
> 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. 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).
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.
> 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
> The other thing that might allow something similar to what I'm looking for
> would be the module-pipe-source/sink pair. Can multiple sources use the
> same FIFO? If so, I could have each MPD app play into a unique
> module-pipe-sink FIFO, and use a module-pipe-source to connect each zone's
> physical sink to the appropriate FIFO.
Currently there is no official way to connect sources to sinks. (parec |
pacat does not deal with the complex timing issues involved).
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 :)
> At least that way I need a more
> manageable number of virtual sources (though it's still ugly)... Even
> *more* hacky, module-pipe-sink could be modified to output to multiple
> FIFO's if necessary, but now we're rapidly approaching the number of
> permutations you would need if you used module-combine...
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
It probably wouldn't take too much to write such a module and avoids
complicated timing problems of connecting sources to sinks.
A simple GUI to define this config file can be a separate app, or it
could be somehow incorporated into a protocol extension for the watchdog
module and hacked into pavucontrol.... If I'm feeling energetic I may
sketch out the requirements for this and hack up an example.
Tribalogic Limited [http://www.tribalogic.net/]
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
More information about the pulseaudio-discuss