[pulseaudio-discuss] why command_cork_playback_stream() will be invoked many times?
Zhang, Xing Z
xing.z.zhang at intel.com
Wed Feb 4 22:36:23 PST 2009
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?
>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
> >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()
> >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
> >and a
> >> VoIP call starts. The user may not want to mix the music and the
> >> call.
> >> So the idea is to pause the music while the call takes place, and
> >> music once the call finishes. PulseAudio receives both streams,
> >> seem natural to configure said behavior in a PulseAudio module. So
> >> need the ability to pause a stream within PulseAudio, or we need a
> >> inform the client they need to pause.
> >> I agree with you that pausing may create timing havoc on the
> >> are missing a generic protocol to notify the clients and implement
> >> 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
> > 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
> > 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
> > 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 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
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
>"A little rudeness and disrespect can elevate a meaningless interaction to
>a battle of wills and add drama to an otherwise dull day." - Calven
More information about the pulseaudio-discuss