On Thu, 2014-05-22 at 09:44 +0200, Sjoerd Simons wrote: > On Mon, 2014-05-19 at 09:57 -0500, Pierre-Louis Bossart wrote: > > > For various use-cases a passthrough stream should have priority over all > > > other streams and get exclusive access to the sink regardless of whether > > > any other streams are playing. > > > > > > An example use-case is ensuring XBMC can successfully start video > > > playback (with passthrough) even if an external notification sound > > > happened to be playing at the same time. > > > > While the code makes sense, I am wondering if this is the right > > solution. This would typically need to be handled by a policy framework > > instead of making hard-coded decisions? > > It's a minimal solution that works for this typical (HTPC) use-case :). > But yes, i agree, in the general case having a more > complete/configurable policy framework would be nice to have (and could > potentially deprecate this solution and e.g. module-role-cork & > module-role-ducking). However until such a framework exist, these > "special-case" modules still make sense imho. > > > what if you get a ringtone, do you really want to keep playing your > > video? > > Short answer: Yes. > > Longer answer: This module does not really change the current status quo > in that regard, even without the module if a passthrough stream is > playing no other audio stream can use that sink. The only thing that > really changes is that a passthrough stream is guaranteed to get > exclusive access when it starts. > > On top of that, unlike all other audio streams, switching from > passthrough to non-passthrough mode has a rather big impact. You can't > duck a passthrough stream (as pulse can't mix it with other streams) and > typically it does take some time for the receiver to switch as well. > Tbh, i'm not even sure if you can sensibly "mute" a passthrough stream > to e.g. allow a ringtone to come through. > > > At the very least there should be a whitelist set of stream > > types that have higher precedence than pass-through and that don't get > > routed to the null sink (could be passed as options to the module) > > Given the above I'm not sure i agree with this. > > I'm happy to add a list of roles which block a passthrough stream from > taking over (e.g. if there is an ongoing phone stream, don't move it > aside to allow passthrough to come through but simply reject the > passthrough as before). I'm wary about changing the logic when it comes > ongoing passthrough streams though as i'm not sure if that will ever > work well. My "ideal" solution for this is to actually have first-class support for kicking out a passthrough stream mid-playback and have the player reconnect for PCM and resume, and vice-versa when notified of non-PCM support being available. At least on GStreamer, we did this with a hack in 0.10, and has not been done the right way on 1.x yet, so this is not something immediately possible. Having a mechanism to have "urgent" notifications override passthrough streams might not be a bad idea (if a ring or alarm comes in, killing off the video might not be the worst thing to do. I'm not too fussed about having this immediately though -- this work should be seen as very specific to the media center case, where you've really got only one client which will hopefully manage the streams itself. We should make sure that potential users of this module are clear about what features it brings, and what the potential downsides are. -- Arun
