[pulseaudio-discuss] [PATCH 1/2] allow-passthrough: Add module to allow passthrough streams always go through

[Sjoerd Simons]

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.


0: Strictly speaking, the first passthrough stream will always get the
   sink.

-- 
Sjoerd Simons <sjoerd at luon.net>