Bug 179639 - stop changing /etc/asound.state file format incompatibly
stop changing /etc/asound.state file format incompatibly
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: alsa-utils (Show other bugs)
4
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Martin Stransky
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-01 15:12 EST by Jamie Zawinski
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-03 03:49:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jamie Zawinski 2006-02-01 15:12:41 EST
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.
Comment 1 Jamie Zawinski 2006-02-01 15:17:18 EST
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
Comment 2 Martin Stransky 2006-02-03 03:49:15 EST
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).
Comment 3 Jamie Zawinski 2006-03-31 23:23:12 EST
> I hope it was the last change in FC4.
Comment 4 Jamie Zawinski 2006-03-31 23:26:43 EST
> 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.
Comment 5 Martin Stransky 2006-04-14 05:30:57 EDT
These changes come from kernel, not from alsa-lib nor alsa-utils so don't update
your (fucking :-)) kernel...

Note You need to log in before you can comment on or make changes to this bug.