[pulseaudio-discuss] Auto-switching to and from HDMI ports (audio)
Dennis Chua
dennis.chua at canonical.com
Fri Mar 16 07:37:28 PDT 2012
Thanks, David, for opening up this discussion.
First all, let me state the obvious by saying that the laptop is
becoming a media hub supporting several modes of audio output. Aside
from the internal-speaker, we now support bluetooth, hdmi and display
port just to name a few.
In it's initial state after power-up, the laptop can have all, some or
no external audio devices. We don't really know what the user's intent
is as far as audio output is concerned -- should we impose one? I don't
think so. Thus, I think having internal-speaker as the default output is
a safe mode for this initial state. From here the user selects the
output depending on the devices available.
Going from this, what should happen once the user adds or subtracts to
the set of audio devices? Once a new device is attached, we can proceed
with the "As You Were Until I Tell You" policy and retain the last
state; that is, the user has to update the output mode. Or do we take
the initiative and update the output channel, as in the case of
attaching headphones or speakers on the analog jack? Similarly, we can
have audio switch back to internal speakers (the initial state) when the
currently-active device is detached.
As far as attachment is concerned, we can look at the system design
goals in terms of:
(1) following the user's intent
(2) acknowledging the event
(3) notifying the user whether or not the new audio mode works.
It appears that any discussion on this topic is typically split with
respect to the first issue -- should we be smart or not?. But I feel
that the second design goal is equally important. To this end, we should
signal the user, either by an OSD sigil (if there's a GUI), a log
message (good for console systems) … or by transferring audio to the
newly-attached device. Finally, the third is most critical because it
tests the new audio channel and conveys the status to the user.
If the consensus is not to be smart about (1), then we should forgo
accomplishing (3) as well. It's best to leave it up to the user to carry
out both (1) and (3) at his own leisure. However, at the least we should
fulfill (2) by OSD or log updates. My own stance is to prefer the
automatic transfer of audio to the new device because this achieves all
goals. Best of all, the user gets immediate feedback about the
workability of the new audio device, design goal (3).
With respect to detachment, if the removed device was the active audio
output, then we should switch to the default (the initial state), which
is internal-speaker. If the detached device was not the active output,
then we apply the "As You Were" policy.
-- Dennis
On 3/16/12 10:31 AM, Christian Giordano wrote:
> I added Steward in the loop who is responsible for the specifications
> for the multi-monitor experience. In the current specs
> <https://docs.google.com/a/canonical.com/document/d/1aHvJ-iIw-59bXTYBmIhQqEx0za2h9jpFE_RhZ2VOvJc/edit>
> there is the possibility of UI being prompted when an unknown display
> is connected for the first time. This panel could eventually contain
> an option for the audio as well.
>
>
> Cheers, chr
>
>
> On Fri, Mar 16, 2012 at 1:48 AM, David Henningsson
> <david.henningsson at canonical.com
> <mailto:david.henningsson at canonical.com>> 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?
>
> 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.
>
> 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.
>
> 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.
>
> 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?
>
> * 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?
>
> * 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?
>
> * 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.
>
> What do you think?
>
> --
> David Henningsson, Canonical Ltd.
> http://launchpad.net/~diwic <http://launchpad.net/%7Ediwic>
>
> [1] The exact same applies to DisplayPort. Seen from userspace,
> DisplayPort and HDMI appears in the same way. I've just written
> HDMI everywhere for simplicity.
>
>
--
Dennis Chua | Professional Engineering Services | Canonical Ltd
10 Maguire Road, Suite 212 | Lexington, MA 02421 USA
dennis.chua at canonical.com | o: +1-781-761-9430, m: +1-917-576-1396
#PES at Canonical, #ubuntu at Freenode IRC: dchua
www.ubuntu.com Ubuntu - Linux for human beings
More information about the pulseaudio-discuss
mailing list