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

[pl bossart]

Hi Lennart,
I like the idea of modules being able to send events to a client. That would
work for clients who connect directly to pulseaudio, with some additional
modifications internally. For example the pulsesink would sent a message on
gst_bus to request the app to pause.

However in the case where apps use ALSA and see the PCM routed to PulseAudio
by the   ALSA-lib pulse plugin, that wouldn't help at all, would it? The
cork request would need to be sent to the original application, using DBUS
or something.
My $0.02
Pierre

On Thu, Feb 5, 2009 at 9:35 PM, 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>
>
> The 'event' string would carry some kind of identifier for the
> event. Initially we'd just define the 'request-cork' and
> 'request-uncork' event identifiers for this. A client should ignore
> all events it doesn't understand. The proplist passed can be used to
> include some additional information about the event. What actually is
> stored in it that proplist depends on the event.
>
> This would then be flexible enough to allow any module that is loaded
> into PA to define their own events, by simple namespacing. For
> example, if module-frobnicate wants to send and event to a particular
> sink input/stream it would send it as "module-frobnicate.foobar". That
> would happen in-line. We could even extend this and add similar
> functionality to pa_context.
>
> Does that sound good to you?
>
> Adding this logic should be doable in about 20 lines of code... Maybe
> I'll find the time to implement this tomorrow, before I leave for the
> airport for FOSDEM.
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20090206/71225d6c/attachment.htm>