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

Lennart Poettering lennart at poettering.net
Thu Feb 5 19:35:17 PST 2009

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

More information about the pulseaudio-discuss mailing list