[pulseaudio-discuss] why command_cork_playback_stream() will be invoked many times?
bossart.nospam at gmail.com
Fri Feb 6 14:04:29 PST 2009
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
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:
> 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);
> 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pulseaudio-discuss