Hi David, On Friday 16 March 2012 03:48:14 David Henningsson wrote: > Hi, > > 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? What I'm most concerned about personally is that the end user should be able to specify the desired behavior. In my opinion, Pulseaudio should only provide the routing mechanisms and configurability, not the policies themselves. Of course, it can provide reasonable defaults, but it's impossible to mandate policies that would work everywhere and for everyone. I think the worst case would be to code some "cleverness" into Pulseaudio which cannot be easily overridden. So, I guess my main question is that how would this functionality be configurable? I wouldn't think tweaking default.pa would be a good option here. > * 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. In my view, this is the only decision that can be made on behalf of the user. But is it necessary to change the default sink the user has set? If the HDMI output becomes available, it could be selected automatically if the user has chosen that way. If the priority is lower than the internal speakers, then it wouldn't be automatically selected. (FWIW, I think the default sink concept is too limiting, and should only be considered as a fallback. Pulseaudio has quite novel routing capabilities based on stream properties, available profiles and ports etc., so why not use those?) All the best, -- Jarkko
