Please sanify asound.state ranges upon dist-upgrade to prevent absurd attenuation

[acidbits]

Upgraded my laptop from gutsy to hardy, amd_64. There is sound, but it's loud and crispy.

lspci:

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
01:00.0 Ethernet controller: Atheros Communications, Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01)
07:08.0 Ethernet controller: Intel Corporation PRO/100 VE Network Connection (rev 02)
07:09.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller
07:09.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19)
07:09.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 0a)
07:09.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 05)
07:09.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev ff)

ProblemType: Bug
Architecture: amd64
Date: Sat Mar 29 20:16:18 2008
DistroRelease: Ubuntu 8.04
ExecutablePath: /usr/bin/yelp
NonfreeKernelModules: ath_hal
Package: yelp 2.22.0-0ubuntu3
PackageArchitecture: amd64
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=ca_ES.UTF-8@valencia
 SHELL=/bin/bash
SourcePackage: yelp
Uname: Linux 2.6.24-12-generic x86_64

[Daniel T Chen (crimsun)]

Make sure that your PCM volume (see alsamixer or amixer output) is set to a level <= %77.

[acidbits (acidbits)]

Thanks. It looks like default level set for PCM is not correct. Just had to open alsamixer, select lower PCM level, rise it up to top again, and now sound is OK.

[Jamie Lokier (jamie-shareable)]

I can confirm this bug on different hardware _and_ the workaround.

I was getting very, very loud and distorted sounds on Hardy after upgrading. (System beep woke my sleeping housemate, hmm.)

Then playing music with Rhythmbox, it was horribly clipped sound as well as loud. A fix in Rhythmbox was to set the app's volume control to just 1 pixel above minimum. Then it sounded about normal. (0 pixels = mute, 2 pixels = noticable clipping). System beep remained ridiculously load.

But then, following acidbits' advice in the previous comment, I opened the GNOME Volume Control (right click on volume control applet, select "Open Volume Control").

The PCM control showed maximum position, and the Master control slightly less.

I adjusted the PCM control down and then back up to maximum position. Since then, sound is fine. Thanks acidbits!

Now I have Rhythmbox's own volume control set to something normal again (i.e. max in the app, not 1 pixel :-).

Note that adjusting the Master control didn't fix it, nor did trying different playback devices in Sound Preferences.

So the PCM mixer control is broken somehow. It's set to an impossible value, way more than maximum (like say 100x amplitude?). Just nudging the slider seems to fix it permanently.

I haven't checked if the fix persists after reboot or suspend.

[Brian Murray (brian-murray)]

Reviewing this bug report and its comments it seems that multiple people are experiencing this problem. Subsequently, I am confirming this bug report. For future reference you can manage the status of bug reports by clicking on the current status in the yellow line and then choosing a new status in the drop down box. You can learn more about bug statuses at http://wiki.ubuntu.com/Bugs/Status .

[Brian Murray (brian-murray)]

I spoke to Daniel Chen on irc about this bug and he indicated that capturing the file '/var/lib/alsa/asound.state' before and after upgrading would be helpful. He also said the following:

15:19 < crimsun> bdmurray: I briefly spoke with someone in +1 about writing a script to parse the state file (/var/lib/alsa/asound.state) parameters on dist-upgrade (well, really between different ALSA-driver versions). This is likely the culprit you guys are seeing - particularly if it's reproducible simply on dist-upgrade (from foo to hardy) in the cli with aplay or paplay

and:

15:21 < crimsun> bdmurray: http://wiki.steenbe.nl/extra/alsachk (by osteenbergen); I don't know if that URL remains valid

[Jamie Lokier (jamie-shareable)]

Brian Murray wrote:
> I spoke to Daniel Chen on irc about this bug and he indicated that
> capturing the file '/var/lib/alsa/asound.state' before and after
> upgrading would be helpful. He also said the following:
>
> 15:19 < crimsun> bdmurray: I briefly spoke with someone in +1 about
> writing a script to parse the state file (/var/lib/alsa/asound.state)
> parameters on dist-upgrade (well, really between different ALSA-driver
> versions). This is likely the culprit you guys are seeing -
> particularly if it's reproducible simply on dist-upgrade (from foo to
> hardy) in the cli with aplay or paplay

I'm thinking that either:

    1. ALSA should be unable to set an "impossible" volume level,
       regardless of contents of /var/lib/alsa/asound.state. So even
       when the parser script is fixed, there's still a bug, where
       some component can be given a bogus parameter which it doesn't
       bounds check.

    2. Or it's an ALSA internal feature that impossibly high volume
       levels can be set. In that case, it's occasionally useful
       (when you're playing very quiet recordings, for example), and
       should be exposed through the normal volume controls, perhaps
       with a switch to disable the normal limit, and with finer
       control than normal/too-much of course :-)

-- Jamie

[Colin Watson (cjwatson)]

alsa-utils (1.0.23-2ubuntu2) maverick; urgency=low

  * debian/init: Restore change from 1.0.21-1ubuntu2 lost during merge
    that skips muting and zeroing levels prior to shutdown/reboot,
    which was a hack for broken drivers. This change closes LP: #21804,
    LP: #208920, #227505, #360108, #432660, #449783, #553132, #564472,
    LP: #584609, #592016, #596360, #613054, #617516, #622487, #632019.
  * debian/patches/alsactl_init_update_to_52bd2f8a_head.patch: Add
    upstream git changesets:
    dcb90a77 - Use "Found hardware:" instead "Unknown hardware:"
    7f6a55e2 - use "generic method" instead "guess method"
    52bd2f8a - Handle "Capture Source" and "Mic Boost"
    ef919a47 - Initialize also "Master Front Playback Volume" & "Switch"
    (yes, this last changeset is included despite the patch filename)

 -- Daniel T Chen <email address hidden> Sun, 05 Sep 2010 11:57:59 -0400