Jack detection for audio
For the next cycle I'd be great if we had better jack detection for audio.
What this means to a user would basically be things like:
* plug an (audio capable) hdmi monitor in, and audio is automatically rerouted to go through HDMI
* plug a headphone in, and not only will the speaker mute, but also, the profile will change so that when you then change the volume, it'll affect the headphone's volume rather than the speaker's volume
* in addition, Nvidia's HDMI has four codecs, and this will remove the need to configure which one is the right one manually
* might be even possible to configure things like line-out being muted on headphones plugged in, like some of our users and customers expect, but I'll leave this without promise for the time being.
* also without promise would be a solution to bug 771150 - to add a dialog box and/or impedance sense for determining what a jack should be used for, or reconfiguration possibilities...?
There are some bits and pieces implemented here and there, but we still need to pull them all together, implement a few missing pieces probably, decide with upstream how this is going to work, etc.
- Chris Van Hoof
- David Henningsson
- David Henningsson
- Series goal:
- Accepted for oneiric
- Milestone target:
- Started by
- Chris Van Hoof on 2011-06-22
- Completed by
- Chris Van Hoof on 2011-09-30
[diwic] collect complete requirements; talk to coling: DONE
[cjcurran] look at UI changes required for sound preferences (instead of pavucontrol) to allow routing reconfiguration: POSTPONED
[cjcurran] Update pavucontrol in archive: DONE
[cjcurran] implement libnotify notifications for hotplug routing changes (see NOTE 1): DONE
[cjcurran] Approach design team about establishing a default behaviour for headphone/mic hotplugging: "keep current routing" vs "change to new device": POSTPONED
[diwic] investigate UI changes (GNOME sound prefs, HW tab) to control default behaviour: POSTPONED
1) Harry and I have worked a solution for this. Unfortunately though notifications for routing changes is not something the design team consider necessary. The code can be found here
2) PulseAudio with jack detection enabled has just landed in Oneiric \o/ (2011-08-16)
== Status (2011-09-30) ==
[vanhoof] Postponing three remaining workitems for the 12.04 cycle, all specific to the relevant changes in the UI. The core components we required to get this support off the ground has landed in 11.10.
== Status (2011-09-07) ==
PulseAudio core patches: Completed and released into Oneiric. Upstream plans to merge patches after 1.0 release.
Udev patch: Landed in Oneiric. Upstream rejects patch.
Kernel (HDMI) patches: Landed in Oneiric (kernel 3.0.0-10.16) \o/
Kernel (Analog headphones/speaker) patches: To be worked out in individual drivers - most newer HDAs are supported in both Ubuntu and upstream, but a lot of older ones are not.
Sound Preferences UI patches: Will not land for Oneiric :-(
Copied from etherpad:
== Overview ==
"What happens when you plug/unplug headphone/
* gather requirements from OEM, community
* synchronise with upstream
== Requirements ==
Scope: covering both new devices (eg USB hotplug) and new outputs (eg headphone jack)
Mute behaviour: click avoidance
* pulse: "ramp to zero"
HDMI: no auto reconfiguration planned
* but user-selectable option to do so?
* difficulty with missing/broken EDID
Issue with separate HDMI ports: correlating to physical outputs, only one or more is ever in use, but it's not evident in advance which one(s) are appropriate.
* eg docking station is sometimes one device, onboard another
* some systems have HDMI and DisplayPort, separate devices feed each
* some DVI ports expose an audio device when using DVI-hdmi adapters.
No current HDMI jack detection events (ie, no input event generated)
* One user case to consider while implementing this, a user has an HDMI cable/monitor/
* priority list of devices?
* One per application, one per role (music/voip/etc), one general
* Applications seeing different configuratios on startup can cause issues
OEM partner request:
* headphone/speaker combination jack: dialog for asking what you plugged in?
* if detection is possible otherwise (eg impedance sense), can we use this?
* sketchy details on driver support & correctness
* requires multiple-layer changes
* requires HDA changes
Different volume control methods
* Probe names
* UCM (Use-case manager)
* targetted at embedded systems, but will work on PCs
New sound preferences (part of control center) to land in GNOME 3; UI looks about the same
We don't provide much routing control in sound preferences.
Lennart says: GNOME sound prefs should be as simple as possible, so no per-application output configuration; make more difficult with large amounts of inputs/
OEMs want simple user cases for "pluggable sound": USB headsets, USB speakers.
* different use cases make this hard
* simple use case is to automatically update to newly-plugged devices?
* find sensible defaults, but make it configurable
Current bug: hotplug device, routing changes to that device, but it starts as muted.
We currently have different behaviour w.r.t. 3.5mm headphone plug vs USB headphone plug.
* Blueprints in grey have been implemented.