[pulseaudio-discuss] Auto-switching to and from HDMI ports (audio)

[Colin Guthrie]

'Twas brillig, and David Henningsson at 16/03/12 01:48 did gyre and gimble:
> I'm not exactly sure who I should send this to, so maybe I'm a little
> too inclusive here. Anyway.
> 
> The use case here is that your laptop speakers are active (or at least
> currently selected) and you plug an HDMI [1] cable in and activate the
> screen.
> Should we, or should we not, automatically change the audio output to be
> to the HDMI output?
> And likewise, when the cable is unplugged / the HDMI screen deactivated,
> should we, or should we not, change the audio output back to the speakers?
> 
> So there's a design decision that needs to be made, and probably quite
> quickly if it should go into PulseAudio 2.0 and/or Ubuntu 12.04.

OK, so firstly this stuff is now touching heavily on the routing
priority list stuff I've been brewing for ages now (thinking, but sadly
not doing - hopefully changing soon).

It's very much in the scope of that work as I'll try and explain below.

> The current behaviour is inconsistent, e g I've got bugs filed for
> Ubuntu 11.10 for machines that switch to HDMI on plug but not from HDMI
> on unplug.

I can see how this can happen. Especially when HDMI is a separate card.
Routing currently doesn't take into consideration the availability of
ports - this is something allowed for in the routing priroity lists
which effectively treat each sink-port as a single routable unit,
allowing you to take a simple laptop card with standard 3.5mm headphones
jack and speakers and an external USB speakers and have a priority list of:

3.5mm Headphones
USB Speakers
Built-in Speakers

Meaning that if you do not have your heaphones of USB plugged in, then
the lappy speakers are used, if you plugin Headphones, they'll be used,
but plugging in USB speakers will do nothing until you unplug your
headphones.

I've documented this here, but please see my answers below first.

http://www.freedesktop.org/wiki/Software/PulseAudio/RFC/PriorityRouting

> To complicate matters, and to go a little bit into the technical stuff,
> the HDMI output is sometimes a separate card, and sometimes on the same
> card as the analog outputs. When I originally wrote
> module-switch-on-port-available, I admit not having thought thoroughly
> about switching between HDMI and analog outputs.

Yeah I suspect that module-switch-on-port-available will die after the
routing priority lists comes into play. As will module-switch-on-connect.

> As I see it we have a couple of options.
> 
>  * no auto switching between HDMI and analog outputs at all. This is
> probably the simplest option. But maybe this is not the most user
> friendly option?

Although perhaps counter intuitive, I would actually say this can be
quite common. If we connect a TV, it's not always that I want the audio
going through it.

>  * full switching. This requires not only profile switching on plug and
> unplug, but also switching between cards, i e moving streams between
> cards, and updating the default sink. More work, but definitely doable.
> I get the feeling that we want to avoid updating the default sink when
> it's not a direct user action though?

I would strongly advise against this. Switching profiles is going to be
tricky as a hack.

In the priority lists (and I've not yet updated the wiki to reflect
this) this problem was discussed on the mailing list.

Different profiles (and ports) may or may not be desirable in different
contexts, but in order to determine that, we have to implement a
priority mechanism for streams.

e.g. consider the bluetooth case where you are currently playing music
when a voip call comes in.

Your bluetooth headset is in the A2DP profile, but needs to switch to
HFC for the voip call. In order to route all the streams, we need to
know that the voip call is higher priority than the music stream. And
thus it gets routed first and the decisions about switching profiles
happens there, and when the music stream is subsequently routed it know
that it cannot touch the profile for auto-switching and has to go else
where.

So without the priority lists infrastructure and without any concept of
stream priorities, any code that is implemented now to do automatic
switching will be a minefield of potential problems and races.

The problem is rather complex. I do have a good idea how to implement a
stream priority mechanism (giving power to customisations and
modularisation, but I do need to write that up on the wiki before I
start working on it.

>  * switching only if the HDMI outputs are on the same card as the analog
> output. This is also simple to achieve, but might be confusing for users
> and support engineers?

This would require automatic profile switching right (and depending if
other cards were present, possibly default device changing and maybe
even stream moving if the streams were rerouted after one sink
disappeared abut before the new one did - tho' that could be
impossible)? I'm not sure that's a good idea to bolt on just now. It can
cause some weird problems as has been highlighted in the past with
people asking for help having patched the code to do this.

>  * switching from HDMI but never to HDMI: assuming we're not certain
> that the user wants to use HDMI audio just because (s)he plugged it in,
> we could quite safely assume that (s)he does not want to use an
> unplugged HDMI cable. However, if we want to do this consistently, we
> still suffer from having to set the default sink.

This option would require "default device change+stream moving" some h/w
and profile switching on others.

I think this is actually a lot more work than you might suspect and I
seriously doubt the problems and races could be debugged before a 2.0
release.

I think the right solution is to get the infrastructure outlined for the
priority list stuff fully spec'ed up and work on it for the 3.0
timeframe. I'm really hoping I'll be able to pull my finger out here,
but I certainly won't turn down people helping out here. I've got a
pretty good idea of how I think it needs to be implemented. I know it's
perhaps been deemed overkill or over design, but it still deals
gracefully with all these kind of scenarios that people are realising
need to be supported so I think, even as a thought experiment, that any
accusations of over design are actually unfounded!


So to be honest, I'd go for option 1. It's certainly not as user
friendly, but I think it's the only realistic option for now given your
timeframes.


Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/