[pulseaudio-discuss] why command_cork_playback_stream() will be invoked many times?

[Jason Taylor]

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)

2009/2/12 Lennart Poettering <lennart at poettering.net>

> On Fri, 06.02.09 04:35, Lennart Poettering (lennart at poettering.net) wrote:
>
> >
> > On Wed, 28.01.09 13:44, Bastian, Waldo (waldo.bastian at intel.com) 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>
>
> 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.
>
> Lennart
>
> --
> Lennart Poettering                        Red Hat, Inc.
> lennart [at] poettering [dot] net         ICQ# 11060553
> http://0pointer.net/lennart/           GnuPG 0x1A015CC4
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>



-- 
"A little rudeness and disrespect can elevate a meaningless interaction to a
battle of wills and add drama to an otherwise dull day." - Calven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20090212/e11a1766/attachment.htm>