Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 180119 - media-sound/alsa-utils - alsactl uses /etc/asound.state /etc/init.d/alsasound uses /var/lib/alsa/asound.state
Summary: media-sound/alsa-utils - alsactl uses /etc/asound.state /etc/init.d/alsasound...
Status: RESOLVED UPSTREAM
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Gentoo ALSA team
URL: https://bugtrack.alsa-project.org/als...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-28 14:46 UTC by Bob Paddock
Modified: 2011-03-30 12:31 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
alsa-utils-1.0.14_rc2-r3.diff (alsa-utils-1.0.14_rc2-r3.diff,436 bytes, patch)
2007-05-29 12:58 UTC, Paul Bredbury
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Bob Paddock 2007-05-28 14:46:52 UTC
alsactl uses /etc/asound.state.

/etc/init.d/alsasound uses /var/lib/alsa/asound.state.

alsactl and alsasound should agree on where asound.state is stored.
You find 'alsactl store' in the forms and WIKI, but this has no effect,
unless you use alsactl -f /var/lib/alsa/asound.state store.

Consistancy between alsasound and alsactl would also be nice, as one
uses 'save' and the other uses 'store', can they both support both?




Reproducible: Always

Steps to Reproduce:
1. Change mixer settings using alsamixer.
2. Use 'alsactl store' per documentation.
3.

Actual Results:  
'alsactl store' has no effect.

Expected Results:  
Settings saved with 'alsactl store' sould actually be used.
Comment 1 Daniel Drake (RETIRED) gentoo-dev 2007-05-28 18:48:12 UTC
If you are using the alsasound init script, under which scenarios would you want to run alsactl manually?
Comment 2 Bob Paddock 2007-05-28 21:34:23 UTC
(In reply to comment #1)
> If you are using the alsasound init script, under which scenarios would you
> want to run alsactl manually?

When everone tells you in the forms that that is the solution to getting
the sound unmuted at boot.  This tread for example, one of many:

http://forums.gentoo.org/viewtopic-t-559378-highlight-alsactl+store.html

alsactl and alsasound should agree on the location of asound.state,
and one should not have to resort to reading /etc/init.d/alsasound to
figure out why things don't work.



Comment 3 Daniel Drake (RETIRED) gentoo-dev 2007-05-28 23:30:38 UTC
Then the forums are wrong. If you put alsasound in a runlevel, you'll get sound mixer levels saved on shutdown and restored on bootup without having to do *anything* else. If you don't then this is a bug in alsasound which you should report here rather than look for workarounds. I still don't think you have any reason to run alsactl manually.
Comment 4 Bob Paddock 2007-05-28 23:43:53 UTC
(In reply to comment #3)
> Then the forums are wrong. If you put alsasound in a runlevel, you'll get sound
> mixer levels saved on shutdown and restored on bootup without having to do
> *anything* else.

> If you don't then this is a bug in alsasound which you should
> report here rather than look for workarounds. I still don't think you have any
> reason to run alsactl manually.

If you want to close this bug report that is ok with me.

I'm not going to waste more time trying to convince anyone
that having alsactl silently do the wrong thing is bad.


Comment 5 Daniel Drake (RETIRED) gentoo-dev 2007-05-29 03:08:12 UTC
alsactl isn't a Gentoo utility -- its an ALSA thing. We generally don't modify upstream binaries unless we have to.

In this case there is a good reason why Gentoo's alsasound init script uses the state location that it does. Yes, this is inconsistent with alsactl's default behaviour, but given that the alsasound init script prevents the user from ever needing to touch alsactl (and is designed this way), I don't see this as an issue. 

Feel free to open another bug detailing why you needed to touch alsactl (i.e. why alsasound doesn't do everything you expect it to). Please remember that the forums do sometimes contain misinformation, so I'd suggest you actually try alsasound independently rather than taking everything on the forums for gold. Thanks.
Comment 6 Petteri Räty (RETIRED) gentoo-dev 2007-05-29 07:31:54 UTC
(In reply to comment #5)
> alsactl isn't a Gentoo utility -- its an ALSA thing. We generally don't modify
> upstream binaries unless we have to.
> 

IMHO it should work if it's installed so I opened bug 180186 for not installed alsactl at all by default.
Comment 7 Paul Bredbury 2007-05-29 09:04:52 UTC
What is the point of Gentoo deciding to use /var/lib/alsa/ instead of /etc/ to store asound.state? It's *confusing*.

alsactl is a commonly-known part of ALSA and should *integrate* with Gentoo.

I have in /etc/conf.d/alsasound:
RESTORE_ON_START="no"
SAVE_ON_STOP="no"

... Because I don't want to mistakenly mess up my sound levels and have them saved. To set my sound levels, I used alsamixer and alsactl. And yet, ALSA automagically restores from /etc/asound.state at startup - which is great, but means that the Gentoo files are nonsense.
Comment 8 Daniel Drake (RETIRED) gentoo-dev 2007-05-29 12:14:57 UTC
(In reply to comment #6)
> IMHO it should work if it's installed so I opened bug 180186 for not installed
> alsactl at all by default.

It does work by default, it just doesn't share the same default data store as alsasound. This should not be a problem because they both work fine indepdendently, and still nobody has presented a reason why they need to use BOTH (plus alsasound is designed so that the user DOESN'T have to care about this stuff).

(In reply to comment #7)
> What is the point of Gentoo deciding to use /var/lib/alsa/ instead of /etc/ to
> store asound.state? It's *confusing*.

/etc is for user-built configuration, /var is for data that needs to persist. Also we store the OSS state data there too, which is too big to put in /etc.

> alsactl is a commonly-known part of ALSA and should *integrate* with Gentoo.

It is integrated with alsasound rather nicely.

> ... Because I don't want to mistakenly mess up my sound levels and have them
> saved. To set my sound levels, I used alsamixer and alsactl. And yet, ALSA
> automagically restores from /etc/asound.state at startup - which is great, but
> means that the Gentoo files are nonsense.

ALSA doesn't do this by default -- you must have set something up yourself. And that's totally fine, and also means that you are unaffected by this "bug" since you are using one but not the other.
Comment 9 Paul Bredbury 2007-05-29 12:58:01 UTC
Created attachment 120612 [details, diff]
alsa-utils-1.0.14_rc2-r3.diff

Oops, my "automagically" was wrong - I put "/usr/sbin/alsactl restore" in /etc/conf.d/local.start ages ago, because the initscript didn't seem to be working. Count me as another newbie (as I was then) who was confused by this half-changed behaviour :)

I still run /etc/init.d/alsasound, to load the alsa modules.

> /var is for data that needs to persist.

Well, this bug is about *confusion*, so let's resolve the confusion by making the default for alsactl consistent - see enclosed patch.
Comment 10 Daniel Drake (RETIRED) gentoo-dev 2007-05-29 14:07:27 UTC
Gentoo often gets criticized for modifying default behaviour of non-Gentoo applications (such as the change you propose) and we don't even do it often! Also, changing this behaviour will cause headache for a number of users who will reboot, have no sound, and then have to figure out what changed.

If you can get that change upstream, we'll take it. Otherwise, it will stay the way it is, unless further reasoning comes up.

It may have confused you, but people who are being confused were obviously confused already if they were using both /etc/init.d/alsasound and alsactl. My suggestion is for you to correct whatever wiki and forums you are reading and leave it at that.
Comment 11 Daniel Drake (RETIRED) gentoo-dev 2007-05-29 14:16:57 UTC
After re-reading comment #0 I think there has been a misunderstanding all along (at least for Bob), so let me clarify how this works:

(In reply to comment #0)
> alsactl and alsasound should agree on where asound.state is stored.
> You find 'alsactl store' in the forms and WIKI, but this has no effect,
> unless you use alsactl -f /var/lib/alsa/asound.state store.

You don't need to run alsactl. The Gentoo / ALSA setup is approximately:

1. configure/compile/install alsa drivers in kernel
2. emerge alsa-utils
3. alsaconf
4. rc-update add alsasound default
5. /etc/init.d/alsasound start
6. configure mixer levels (e.g. using alsamixer)

And that's it -- no running of alsactl is required. When you shut down or reboot, the alsasound init script will save your volume levels, and on boot it will restore them. You never have to touch alsactl or worry about where state data is saved.

There is more detailed documentation here:
http://www.gentoo.org/doc/en/alsa-guide.xml
Comment 12 Petteri Räty (RETIRED) gentoo-dev 2007-05-29 15:25:14 UTC
How about we make /etc/asound.state a symlink to /var/lib/alsa/asound.state?
Comment 13 Daniel Drake (RETIRED) gentoo-dev 2007-05-29 15:27:48 UTC
I'd rather not, as I still don't see sufficient reasoning here. It raises many questions regarding migration:

What happens if there is already an /etc/asound.state file? Do we move it to /var/lib/alsa/asound.state? If so, what if there is also a /var/lib/alsa/asound.state file -- do we overwrite it? etc...
Comment 14 Paul Bredbury 2007-05-29 16:51:12 UTC
Debian & Ubuntu have changed the default location for asound.state in alsactl as in my patch (but, strangely, kept asound.names in /etc). From the diffs at:

http://packages.debian.org/stable/sound/alsa-utils
http://packages.ubuntu.com/dapper/sound/alsa-utils
http://packages.ubuntu.com/feisty/sound/alsa-utils

-#define SYS_ASOUNDRC "/etc/asound.state"
+#define SYS_ASOUNDRC "/var/lib/alsa/asound.state"

Hopefully this strengthens the argument for the patch. It's expected that the *default* file location will be a sensible one, and will be *used*.

Let's consider the target audience for Gentoo - an experienced Linux user, who has set up ALSA in multiple distros using their initscripts and *alsactl*, and wants to set up ALSA in Gentoo without reading yet more official documentation which doesn't contain much that he didn't know before.

So, he sets up the initscript *without* reading through its bash script or the Gentoo doc, sets up rc-update and /etc/conf.d/alsasound, runs "alsactl store" after quickly checking "man alsactl", and reboots. Then curses when he sees an error message regarding /var/lib/ scrolling quickly out of sight, up the screen.

Neither /etc/conf.d/alsasound or the ALSA emerges show a warning that alsactl's normal file location is *ignored*. Which comes as a surprise.
Comment 15 Daniel Drake (RETIRED) gentoo-dev 2007-05-29 17:59:54 UTC
(In reply to comment #14)
> Debian & Ubuntu have changed the default location for asound.state in alsactl
> as in my patch (but, strangely, kept asound.names in /etc).

Nice find -- this will help you argue it upstream.

> So, he sets up the initscript *without* reading through its bash script or the
> Gentoo doc, sets up rc-update and /etc/conf.d/alsasound, runs "alsactl store"
> after quickly checking "man alsactl", and reboots. Then curses when he sees an
> error message regarding /var/lib/ scrolling quickly out of sight, up the
> screen.

This will not happen. "alsactl store" will succeed, writing to /etc/asound.state. Then on shutdown, alsasound will save state to /var/lib/alsa/asound.state. On next boot, alsasound will restore sound from /var/lib/alsa/asound.state. No error messages will be appear, and mixer levels will be accurately restored.

Fancy trying with another equally unlikely fictional scenario? :)
Comment 16 Paul Bredbury 2007-05-29 21:11:03 UTC
> Then on shutdown, alsasound will save state

No, this fictional character (named Fred, incidentally) has SAVE_ON_STOP="no", for the same reason as me. So he will be inconvenienced.

The Debian bug tracking the move to /var/lib/alsa (started in 2001) is:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=106244

Here's the new upstream bug:
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3128
Comment 17 Daniel Drake (RETIRED) gentoo-dev 2007-05-29 21:25:45 UTC
Thanks. It would help if you attached the debian patches there so that people are clear on exactly what you are proposing. You should also clarify that we're aware that the location can be overridden with -f, but we'd like to see the default changed.
Comment 18 Daniel Drake (RETIRED) gentoo-dev 2007-06-29 23:17:29 UTC
OK, we'll keep an eye on the upstream bug. Thanks for reporting it.
Comment 19 Paul Bredbury 2011-03-30 12:31:54 UTC
Hooray, nearly 4 years later, it's 99% fixed upstream :)

https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3128