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>
