Improve the audio stability and experience for users

Registered by Robbie Williamson

Determine how to resolve various issues around audio, specifically:
*Volume Scaling: A user expects that the sound level changes in relation to the slider shown by the volume control applet. That is, if the slider moves from the middle (50%) to the right by another 25%, that the sound should increase by the same magnitude. Currently, sound scales linearly (versus logarithmically), which makes it difficult for users to control, with some level of detail, the sound levels at the upper and lower ends.

*Suspend/Resume: A user is listening to music and needs to suspend his/her machine. Upon resuming, the music should resume play from the point at which the machine went into suspend. If the user is listening to music via external devices, e.g. bluetooth headphones or USB speakers, at the time of suspend, the music should resume through the same device.

*Sound Device Preferences: A user chooses the "Preferences" option from the Volume Control applet to select the sound input/output device he/she wishes to use. The user expects to see choices equal to the number of supported sound devices, i.e. PC Speakers, Headphones, USB Speakers, Bluetooth speakers, etc. Currently, the user is presented with more options than devices, that more than often have cryptic labels that make it difficult to determine what input/output sound device they match to.

*Apport Hooks for ALSA: A user has an application using ALSA for sound. For some reason sound stops working, and the user wishes to report a problem via apport. Apport should gather relevant data from ALSA for debugging the issue.

Blueprint information

Status:
Complete
Approver:
Martin Pitt
Priority:
High
Drafter:
Luke Yelavich
Direction:
Needs approval
Assignee:
Luke Yelavich
Definition:
Approved
Series goal:
None
Implementation:
Implemented
Milestone target:
None
Started by
Martin Pitt
Completed by
Martin Pitt

Related branches

Sprints

Whiteboard

Work items:
Promote gnome-volume-control-pulse back to main, and include it in the seeds: TODO
Remove the current gstreamer based mixer applet from the panel: TODO
Check that a bluetooth audio device works with pulseaudio: DONE
Add pulseaudio-module-bluetooth to the seeds: DONE
Check that bluetooth devices still play audio after a suspend/resume cycle: DONE
Check commonly used applications that do not directly support pulseaudio, to ensure they function properly with pulseaudio via the alsa pulseaudio plugin: TODO
Check that USB devices still play audio after a suspend/resume cycle: DONE

pitti, 2009-06-18:
 - Please integrate remaining relevant BoF notes from whiteboard into spec, and remove them from whiteboard
 - [UI changes] It isn't possible to autodetect the speaker configuration (5.1 vs. stereo, etc.)? It seems a little weird having to explicitly configure this in the applet. If that's a technical limitation, ok, please point this out in the spec then.
 - I would like to see "Commonly used applications" expanded to an actual app list, so that we can write a test plan.
 - [migration] Deleting ~/.asoundrc/.pulse can and should happen semi-automatically with https://wiki.ubuntu.com/InteractiveUpgradeHooks
 - [migration] /etc/asound.conf: Can the package preinst decide whether there are just obsolete settings there, and just remove/rename to .dpkg-old? If it's a complex file, we shouldn't bother, since the user explicitly configured it, and thus there's not a lot we should do for automatic migration.

pitti, 2009-06-19: approved

awe, 2009-06-30:

== Volume Scaling ==

 * At UDS, I recall Daniel Chen saying ( I could be wrong ) that volume scaling shouldn't be a problem if the ASLA mixer is set to a fixed volume ( 80%? 90%? ), and the user only uses the pulse audio applet to control the volume. In theory, the Pulseaudio mixer does a better job at scaling volume than does ALSA.
 * I've seen this problem reported on multiple netbooks. In one case, we fixed it by reducing the number of volume steps made available to userspace by the ALSA driver's master volume control.
 * In general, the idea is that more of the volume control's range as a slider, actually translates to audible volume changes. The current applet on my Macbook for instance, isn't use-able from 50% or less.

== Suspend / Resume ==

 * The blueprint says: ''Upon resuming, the music should resume play from the point at which the machine went into suspend.''. Are we sure this is what all users want? Say I was playing music at home, suspended my machine and then went to the library... could be embarassing.
 * I know for a fact that many of the OEM projects have been customized to explicitly pause playback ( and recording in some cases ) during suspend in order to prevent stuttering / distortion during suspend. Perhaps newer versions of Pulse address this problem?

== Work Items ==

 * If we remove the current gstreamer-based applet, is there anyway from the UI for a user to get at ALSA's mixer? This is useful for cases where a user's system upgrades, but some mixer control is improperly muted and/or lowered in value.
 * ''Check commonly used applications that do not directly support pulseaudio...'' -- Is ALSA Pulseaudio plugin currently enabled in Jaunty, or this is a change being made for Karmic?
 * There are two work items for suspend/resume testing of USB and Bluetooth. What were the results? With what kernel/versions of ALSA? Could userspace changes to Bluetooth have any positive effects on BT suspend/resume playback?

== re: pitti's comments ==

 * auto-detect speakers -- I don't think this is possible unless your output device informs the system ( via USB or BT ) what configuration it supports. At some point jack detection might work, but I think this is always going to need a manual control.
 * /etc/asound.conf -- if it's there, we notify the user, but don't touch it. No chance of merging as it's normally not present, so there are no normal settings.

== Implementation ==

 * Nothing is mentioned about glitch-free kernel configurations. Daniel states on his blog that there's no chance any of these changes will land in the Karmic kernel. Are we investigating making glitch-free kernels available via a PPA? How do we work towards getting these changes in the Karmic+1 kernel?
 * Do we have expectations as to what the final versions of ALSA kernel/userspace and Pulse will be yet? Karmic already has ALSA 1.0.20 in the kernel. Is there an expectation that there'll be a 1.0.21 from upstream during this cycle?

== UI Changes ==

 * bullet #2 - ''volume adjustment''
  * the applet controls the volume of the Pulse audio server's output, not the hardware volume.
  * the current applet ( 2.26.0-0ubuntu3 ) doesn't allow the output device to be specified per application. Is upstream working on this feature?
 * bullet #3 - ''speaker configuration''
  * is upstream working on this?
  * will the UI be dynamic based on hardware capabilities?

== Code Changes ==

 * additional applications to check:
  * Skype
  * Audacity
  * GStreamer -- used by a lot of applications
  * RealPlayer
  * Ekiga
  * MPlayer

Q&A
-------
Volume Control: actually, the use of keyboard shortcuts increases/decreases the volume in a few, fixed steps; can't it be modified to work like mouse scrolling? something more fluid, maybe controlled with a logarithmic function: the more I keep my key pressed, the faster volume decreases.

  -- awe: maybe, but I the volume scaling problem is really a result of the way the underlying mixer works.

Device Selection: If a user selects a new device, should all existing playing streams be moved to that device, or just new ones? Should it be an option? Currently if you change the default sink for pulseaudio, then you have to restart the application to get the audio stream to move (or play about in the pulseaudio volume control).

  -- pitti: I don't think that there's a clear answer to that. In most cases I'd find it annoying to get existing streams automatically switched over just because I plug in an USB headset because I'm about to do a SIP call. I'd opt for keeping existing streams and making it easy to switch over everything to a different device.

  -- awe: i agree with pitti. I don't think auto-switchover is the way to go.

Since I don't understand the volume scaling stuff, I've asked for assistance to get that part sorted out, however I've seen no additions for this yet.

(?)

Work Items