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

Lennart Poettering lennart at poettering.net
Thu Jan 22 14:36:13 PST 2009


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



More information about the pulseaudio-discuss mailing list