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
