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

[Zhang, Xing Z]

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: pulseaudio-discuss-bounces at mail.0pointer.de [mailto:pulseaudio-
>discuss-bounces at mail.0pointer.de] 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: pulseaudio-discuss-bounces at mail.0pointer.de
>[mailto:pulseaudio-
>	>discuss-bounces at mail.0pointer.de] On Behalf Of Lennart Poettering
>	>Sent: 2009年1月23日 6:36
>	>To: pulseaudio-discuss at mail.0pointer.de
>	>Subject: Re: [pulseaudio-discuss] why command_cork_playback_stream()
>will
>	>be invoked many times?
>	>
>	>On Tue, 20.01.09 10:13, pl bossart (bossart.nospam at gmail.com) 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
>	>pulseaudio-discuss at mail.0pointer.de
>	>https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>	_______________________________________________
>	pulseaudio-discuss mailing list
>	pulseaudio-discuss at mail.0pointer.de
>	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