<div>Hi Lennart,</div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div>My $0.02</div>
<div>Pierre<br><br></div>
<div class="gmail_quote">On Thu, Feb 5, 2009 at 9:35 PM, Lennart Poettering <span dir="ltr"><<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="Ih2E3d">On Wed, 28.01.09 13:44, Bastian, Waldo (<a href="mailto:waldo.bastian@intel.com">waldo.bastian@intel.com</a>) wrote:<br><br>> > 2) Add a GStreamer interface for events like this.<br>> ><br>
> > 3) If a client doesn't handle these request the streams in question<br>> > should simply be muted/unmuted.<br>><br>> The problem that I see with this approach is that executing the<br>> policy will have a dependency on the application responding quickly<br>
> enough and behaving properly. What about starting with step 3) -><br>> Mute the audio stream and then do step 1) and 2) after that to let<br>> the application know that it might be a good idea to pause?<br>><br>
> I think such approach would also combine better with volume ramping:<br>> policy engine could fade out the stream before muting it and then<br>> advice application to pause. Thoughts?<br><br></div>Yes, I actually thought about this too. I guess PA generally should<br>
not depend on the client's stability to work properly. Hence yes, I<br>agree that this kind of "synchronous" communication as I originally<br>suggested above is a bad idea. The server should never have to 'wait'<br>
for a client to make decisions.<br><br>Hence I would simply add a simple, asynchronous notification<br>system. Something like this:<br><br><snip><br>typedef void (*pa_stream_event_cb_t)(pa_stream *p, const char *event, pa_proplist *proplist, void *userdata);<br>
<br>void pa_stream_set_event_callback(pa_stream *p, pa_stream_event_cb_t cb, void *userdata);<br></snip><br><br>The 'event' string would carry some kind of identifier for the<br>event. Initially we'd just define the 'request-cork' and<br>
'request-uncork' event identifiers for this. A client should ignore<br>all events it doesn't understand. The proplist passed can be used to<br>include some additional information about the event. What actually is<br>
stored in it that proplist depends on the event.<br><br>This would then be flexible enough to allow any module that is loaded<br>into PA to define their own events, by simple namespacing. For<br>example, if module-frobnicate wants to send and event to a particular<br>
sink input/stream it would send it as "module-frobnicate.foobar". That<br>would happen in-line. We could even extend this and add similar<br>functionality to pa_context.<br><br>Does that sound good to you?<br><br>
Adding this logic should be doable in about 20 lines of code... Maybe<br>I'll find the time to implement this tomorrow, before I leave for the<br>airport for FOSDEM.<br>
<div class="Ih2E3d"><br>Lennart<br><br>--<br>Lennart Poettering Red Hat, Inc.<br>lennart [at] poettering [dot] net ICQ# 11060553<br><a href="http://0pointer.net/lennart/" target="_blank">http://0pointer.net/lennart/</a> GnuPG 0x1A015CC4<br>
_______________________________________________<br></div>
<div>
<div></div>
<div class="Wj3C7c">pulseaudio-discuss mailing list<br><a href="mailto:pulseaudio-discuss@mail.0pointer.de">pulseaudio-discuss@mail.0pointer.de</a><br><a href="https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss" target="_blank">https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss</a><br>
</div></div></blockquote></div><br>