[pulseaudio-discuss] Moving sources and sinks
lennart at poettering.net
Mon May 5 17:46:16 PDT 2008
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 Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the pulseaudio-discuss