[pulseaudio-discuss] Moving sources and sinks

[Lennart Poettering]

On Fri, 02.05.08 11:01, Nick Thompson (rextanka at comcast.net) wrote:

> 
> 
> Awesome Matt, if you can share your source I would love to see it.
> 
> What you are doing sounds interesting.
> 
> For my app I'd like to have two classes of data.  For arguments sake  
> these are "normal" and "alert".  Normal audio (mp3, wav, application  
> data) needs to be routed to the currently selected output.  Alert  
> audio, which would include system sounds, tactile feedback and the  
> like, would need to be routed to a different source (and possibly also  
> the default output source as well).  Initially I was looking at some  
> sort of stream tagging mechanism using something like the class filed  
> in ALSA, but this is clunky and I cannot guarantee that all audio will  
> pass through alsa (for example the gstreamer pulse plugin looks  
> interesting for certain apps).  At the moment I'm trying to prototype  
> this on a regular x86 desktop system, later I'll move it to an  
> embedded system, once I've figured out a means to implement it.
> 
> It think the issue I have can be described as follows: based on my  
> current understanding I would need to track every stream to determine  
> where to route it.  I'd like to cluster my normal and alert streams  
> together and route them all en-masse to a sink.

As mentioned, in the glitch-free branch you have those properties you
can attach to each stream. To implement policy routing a module should
be written that hooks into the stream creation code (similar to what
module-volume-restore already does) looks for the "class" property and
adjusts the sink the stream is attached to properly.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4