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
