Thats cool... I've been playing around with some roles with python, things of noticed so far... - A paused (no one uses stop any more right?) music/video player will still have an active stream (both banshee and rhythmbox do this) blocking other music players, - Muting music players for totem-audio-preview (mouse hover on music file in nautilus) is really nice - Flash is a pain.. - It would be nice to be able to set the role manually some how for a client using the alsa plugin (skype, flash etc) - Multiple music/video players + ability to mute based on window focus is cool (especially if it fades) <div class="gmail_quote">2009/2/12 Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="Ih2E3d">On Fri, 06.02.09 04:35, Lennart Poettering (<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>) wrote: > > On Wed, 28.01.09 13:44, Bastian, Waldo (<a href="mailto:waldo.bastian@intel.com">waldo.bastian@intel.com</a>) wrote: > > > > 2) Add a GStreamer interface for events like this. > > > > > > 3) If a client doesn't handle these request the streams in question > > >   should simply be muted/unmuted. > > > > The problem that I see with this approach is that executing the > > policy will have a dependency on the application responding quickly > > enough and behaving properly. What about starting with step 3) -> > > Mute the audio stream and then do step 1) and 2) after that to let > > the application know that it might be a good idea to pause? > > > > I think such approach would also combine better with volume ramping: > > policy engine could fade out the stream before muting it and then > > advice application to pause. Thoughts? > > Yes, I actually thought about this too. I guess PA generally should > not depend on the client's stability to work properly. Hence yes, I > agree that this kind of "synchronous" communication as I originally > suggested above is a bad idea. The server should never have to 'wait' > for a client to make decisions. > > Hence I would simply add a simple, asynchronous notification > system. Something like this: > > <snip> > typedef void (*pa_stream_event_cb_t)(pa_stream *p, const char *event, pa_proplist *proplist, void *userdata); > > void pa_stream_set_event_callback(pa_stream *p, pa_stream_event_cb_t cb, void *userdata); > </snip> </div>I have now implemented this. It's available in git master. I also implemented a little module that will pause/mute all video/music streams as long a s a phone stream is existant. Works quite well. You can test it with this:   PULSE_PROP="media.role=music" pacat some-signal.raw And then on another terminal:   PULSE_PROP="media.role=phone" pacat some-other-signal.raw And as long as the latter is running the former will be muted. Also, you will see the pause/resume request messages. <div><div></div><div class="Wj3C7c"> Lennart -- Lennart Poettering                        Red Hat, Inc. lennart [at] poettering [dot] net         ICQ# 11060553 <a href="http://0pointer.net/lennart/" target="_blank">http://0pointer.net/lennart/</a>           GnuPG 0x1A015CC4 _______________________________________________ pulseaudio-discuss mailing list <a href="mailto:pulseaudio-discuss@mail.0pointer.de">pulseaudio-discuss@mail.0pointer.de</a> <a href="https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss" target="_blank">https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss</a> </div></div></blockquote></div> -- "A little rudeness and disrespect can elevate a meaningless interaction to a battle of wills and add drama to an otherwise dull day." - Calven