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

[Bastian, Waldo]

> On Tue, 20.01.09 10:13, pl bossart (bossart.nospam at gmail.com) wrote:
> > 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.

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