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>
