> On Tue, 20.01.09 10:13, pl bossart ([email protected]) wrote: > > 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.
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? Cheers, Waldo _______________________________________________ pulseaudio-discuss mailing list [email protected] https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
