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
