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

[Jason Taylor]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20090205/65d5c8e1/attachment.htm>