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

[Zhang, Xing Z]

Sorry for late reply, I am just back from holidays.
Yes, we are on the similar way as you said.
Now we are working on enhance PA to introduce policy engine to it. To avoid
do changes on PA core code, we implement the engine as a individual module.
We hope the module is expandable and flexible. The engine is not only suit for PC but also for embedded system which has specific audio hardware.
Now we are in heavy developing, once codes are ready I will send out the patch for review. Thanks. 

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