From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/417.9 (KHTML, like Gecko) Safari/417.8 Description of problem: I need very particular volume settings on my sound card, so I am careful to back up /etc/asound.state so that it doesn't get randomly changed on me. Just about every time "yum update" feeds me a new version of Alsa, my saved asound.state file is invalidated. The last time this happened, I had to re-create my settings from scratch. This time, it seemed to save the settings, but I had to spend a lot of time verifying that it hadn't screwed anythingup anyway, and manually comparing the old file and the new file. Please stop changing the format of this file. As you can see from the attached diffs, the changes that are being made to this file are trivial syntax changes -- and yet, they render the old files unreadable by the new versions of the software. This is not some private, internal thing you can just tweak willy-nilly -- this is user-visible data that stores important preferences! It has to be stable! If changes to the file format are ever truly needed, then add a version number to the file format and auto-upgrade the old files. I know you (Red Hat/Fedora) are probably just upgrading to the upstream version, and these bad decisions are being made by someone else, but please, you have to solve this problem. Either by being more careful about what patches you accept, or by considering a change to the format of alsa.state to be a major-number change, and holding it for the next full release of the OS. Version-Release number of selected component (if applicable): alsa-utils-1.0.10-1.FC4 How reproducible: Always Steps to Reproduce: 1. attempt to hang on to your sound card settings; 2. discover that your last yum upgrade has given you a new alsa; 3. waste half a day re-constructing your settings. Actual Results: /etc/asound.state became invalid. Expected Results: As I did not repace my sound card, I shouldn't even have noticed that anything changed. Additional info: Feel the love: % diff -U1 asound.state.2005 asound.state.2006 --- asound.state.2005 2005-10-06 00:54:54.000000000 -0700 +++ asound.state.2006 2006-02-01 11:48:14.000000000 -0800 @@ -403,2 +403,3 @@ iface PCM + device 2 name 'Captured FX8010 Outputs' @@ -730,3 +731,3 @@ comment.range '0 - 15' - iface MIXER + iface PCM name 'EMU10K1 PCM Send Routing' @@ -750,3 +751,3 @@ comment.range '0 - 15' - iface MIXER + iface PCM name 'EMU10K1 PCM Send Routing' @@ -771,3 +772,3 @@ comment.range '0 - 15' - iface MIXER + iface PCM name 'EMU10K1 PCM Send Routing' ... and so on, for ~150 similar changes.
I forgot to mention: what happens when I try to load the old file is ~750 lines of error messages like the following: alsactl: set_control:890: warning: device mismatch (0/2) for control #42 alsactl: set_control:892: warning: subdevice mismatch (0/0) for control #42 alsactl: set_control:894: warning: name mismatch (Captured FX8010 Outputs/Captured FX8010 Outputs) for control #42 alsactl: set_control:896: warning: index mismatch (0/0) for control #42 alsactl: set_control:888: warning: iface mismatch (2/3) for control #81 alsactl: set_control:890: warning: device mismatch (0/0) for control #81 alsactl: set_control:892: warning: subdevice mismatch (0/0) for control #81 alsactl: set_control:894: warning: name mismatch (EMU10K1 PCM Send Routing/EMU10K1 PCM Send Routing) for control #81 alsactl: set_control:896: warning: index mismatch (0/0) for control #81 alsactl: set_control:888: warning: iface mismatch (2/3) for control #82 alsactl: set_control:890: warning: device mismatch (0/0) for control #82 alsactl: set_control:892: warning: subdevice mismatch (0/0) for control #82 alsactl: set_control:894: warning: name mismatch (EMU10K1 PCM Send Routing/EMU10K1 PCM Send Routing) for control #82 alsactl: set_control:896: warning: index mismatch (1/1) for control #82 alsactl: set_control:888: warning: iface mismatch (2/3) for control #83 alsactl: set_control:890: warning: device mismatch (0/0) for control #83 alsactl: set_control:892: warning: subdevice mismatch (0/0) for control #83 alsactl: set_control:894: warning: name mismatch (EMU10K1 PCM Send Routing/EMU10K1 PCM Send Routing) for control #83
I hope it was the last change in FC4. btw. you don't have to update alsa-lib/alsa-utils if your system works properly (old alsa-lib usually works fine with new drivers and vice versa).
> I hope it was the last change in FC4.
> I hope it was the last change in FC4. Yeah, I hoped so too, but it wasn't; you fucked it up again in alsa-lib-1.0.10-3.FC4 / alsa- utils-1.0.10-1.FC4: alsactl: set_control:886: warning: numid mismatch (15/18) for control #15 alsactl: set_control:888: warning: iface mismatch (2/2) for control #15 alsactl: set_control:890: warning: device mismatch (0/0) for control #15 alsactl: set_control:892: warning: subdevice mismatch (0/0) for control #15 alsactl: set_control:894: warning: name mismatch (AC97 Playback Volume/AC97 Playback Volume) for control #15 alsactl: set_control:896: warning: index mismatch (0/0) for control #15 alsactl: set_control:894: warning: name mismatch (AC97 Capture Volume/Front Capture Volume) for control #16 alsactl: set_control:896: warning: index mismatch (0/0) for control #16 alsactl: set_control:898: failed to obtain info for control #16 (Operation not permitted) So out of curiosity -- do you think my complaint and recommendation are silly, or do you just not *care* about the inconvenience this causes for people who are actually trying to get work done? This costs me like half a day of fucking around every time I upgrade this machine. It's really, really getting tiresome.
These changes come from kernel, not from alsa-lib nor alsa-utils so don't update your (fucking :-)) kernel...