Is there a spec/blueprint for this some where? <div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> >-----Original Message----- >From: <a href="mailto:pulseaudio-discuss-bounces@mail.0pointer.de" target="_blank">pulseaudio-discuss-bounces@mail.0pointer.de</a> [mailto:<a href="mailto:pulseaudio-" target="_blank">pulseaudio-</a> ><a href="mailto:discuss-bounces@mail.0pointer.de" target="_blank">discuss-bounces@mail.0pointer.de</a>] On Behalf Of Lennart Poettering >Sent: 2009年1月23日 6:36 >To: <a href="mailto:pulseaudio-discuss@mail.0pointer.de" target="_blank">pulseaudio-discuss@mail.0pointer.de</a> >Subject: Re: [pulseaudio-discuss] why command_cork_playback_stream() will >be invoked many times? > >On Tue, 20.01.09 10:13, pl bossart (<a href="mailto:bossart.nospam@gmail.com" target="_blank">bossart.nospam@gmail.com</a>) wrote: > >> Hi Lennart, >> Here is the use case Xing is referring to: you are listening to music, >and a >> VoIP call starts. The user may not want to mix the music and the speech >> call. >> >> So the idea is to pause the music while the call takes place, and resume >the >> music once the call finishes. PulseAudio receives both streams, and it >would >> seem natural to configure said behavior in a PulseAudio module. So we >either >> need the ability to pause a stream within PulseAudio, or we need a means >to >> inform the client they need to pause. >> >> I agree with you that pausing may create timing havoc on the client; but >we >> are missing a generic protocol to notify the clients and implement this >> legitimate use case. > >This issue has come up before. e.g. Nokia folks needs this kind of >policy enforcing module, too. > >Simply pausing client streams without having explicit client support >for it is not really an option though. So I generally think the way >forward is like this: > >1) Add an API to PA to allow informing clients of policy requests from the >   server. i.e. add some mechanism so that clients that allocate a >   pa_stream object can set a callback that is called whenever some >   policy engine inside PA wants the client to stop/pause/resume >   playback or has similar requests. It would then be up to the >   client to actually do something about it and then pause the stream >   and update the UI accordingly. > >   Such an "inline" policy request notification subsystem should be >   trivial to add. This should probably be extensible so that we can add >   further notifications such as keypresses from BT devices or jack >   sensing events from the sink. > >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. > >That's the rough plan I have. Patches always welcome. > >Lennart > >-- >Lennart Poettering                        Red Hat, Inc. >lennart [at] poettering [dot] net         ICQ# 11060553 ><a href="http://0pointer.net/lennart/" target="_blank">http://0pointer.net/lennart/</a>           GnuPG 0x1A015CC4 >_______________________________________________ >pulseaudio-discuss mailing list ><a href="mailto:pulseaudio-discuss@mail.0pointer.de" target="_blank">pulseaudio-discuss@mail.0pointer.de</a> ><a href="https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss" target="_blank">https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss</a> _______________________________________________ pulseaudio-discuss mailing list <a href="mailto:pulseaudio-discuss@mail.0pointer.de" target="_blank">pulseaudio-discuss@mail.0pointer.de</a> <a href="https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss" target="_blank">https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss</a> </blockquote></div> -- "A little rudeness and disrespect can elevate a meaningless interaction to a battle of wills and add drama to an otherwise dull day." - Calven