What spec/blueprint you want?
If you are asking how to resolve problem mentioned in the thread. Pls see below 
mail:

>  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.

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?

Cheers,
Waldo

>-----Original Message-----
>From: [email protected] [mailto:pulseaudio-
>[email protected]] On Behalf Of Jason Taylor
>Sent: 2009年2月5日 14:33
>To: General PulseAudio Discussion
>Subject: Re: [pulseaudio-discuss] why command_cork_playback_stream() will
>be invoked many times?
>
>Is there a spec/blueprint for this some where?
>
>
>
>
>       >-----Original Message-----
>       >From: [email protected]
>[mailto:pulseaudio-
>       >[email protected]] On Behalf Of Lennart Poettering
>       >Sent: 2009年1月23日 6:36
>       >To: [email protected]
>       >Subject: Re: [pulseaudio-discuss] why command_cork_playback_stream()
>will
>       >be invoked many times?
>       >
>       >On Tue, 20.01.09 10:13, pl bossart ([email protected]) 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
>       >http://0pointer.net/lennart/           GnuPG 0x1A015CC4
>       >_______________________________________________
>       >pulseaudio-discuss mailing list
>       >[email protected]
>       >https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>       _______________________________________________
>       pulseaudio-discuss mailing list
>       [email protected]
>       https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>
>
>
>
>
>--
>"A little rudeness and disrespect can elevate a meaningless interaction to
>a battle of wills and add drama to an otherwise dull day." - Calven

_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Reply via email to