<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
So I think what I would do is make a "combined" sink for each class of
data that routes all audio to all sources. If you disable the module to
gets rid of idle streams this will leave you with active but corked
streams to all output devices from each sink. You can then update which
streams are muted. If you need to do this literally stream by stream
(as in playback event by playback event) this might not work because I
am just using the text interface (basically what pacmd is) and would
have no way of being notified when a new stream is played. If on the
other hand the routing is more global and based on external events you
could easily update the current config and then all future sounds would
play as expected.<br>
<br>
I'm not at home right now, but I will try to remember to forward my
code tonight or tomorrow morning. If you really can't wait I sent an
older version to the mailing list a while back, it should be in the
archives.<br>
<br>
Matt<br>
<br>
<br>
Nick Thompson wrote:
<blockquote cite="mid:9FAAEBFD-E374-4731-97DF-BDBC72D48A79@comcast.net"
 type="cite">
  <pre wrap="">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.

Thanks!!

Nick


On May 2, 2008, at 10:37 AM, Matt Patterson wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">I do agree that coding for pulse can be a steep learning curve,  
which is why I opted to build all my solutions by simply connecting  
to the text mode control socket and sending commands/parsing text  
output. I have built what is essentially a multiplex audio switch  
allowing any of x number input sources to play out of any x number  
of output sinks, all controlled via a python or php app.
    </pre>
  </blockquote>
  <pre wrap=""><!---->_______________________________________________
pulseaudio-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:pulseaudio-discuss@mail.0pointer.de">pulseaudio-discuss@mail.0pointer.de</a>
<a class="moz-txt-link-freetext" href="https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss">https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss</a>
  </pre>
</blockquote>
</body>
</html>