[gentoo-amd64] Re: Alsa Config keeps disappearing

[Duncan]

sean <tech.junk@×××××××××××.net> posted 4A4B6572.8000308@×××××××××××.net,
excerpted below, on  Wed, 01 Jul 2009 09:32:34 -0400:

>> This sounds to me like one of the sound modules isn't loaded.  ALSA has
>> always started muted, until it's unmuted, but that can't be it, as xine
>> should then play, it'd just be muted.  But if one of the necessary
>> modules wasn't loaded, xine would presumably detect that by the failure
>> to open the device at all, thus the xine-out.wav.
>
> All modules are loaded. In fact I just rebuilt my kernel yesterday and
> repopulated the modules that are to load on startup, and still the same
> problem.
>
> As a regular user, if I start alsamixer and see basically a display with
> no channels, I need to rerun alsaconf as root. Once done, alsamixer
> looks proper with all the channels. The only channel that is muted after
> this, is the mic channel.


So you're saying that it only happens as a regular user?  You can run 
alsamixer as root and see all channels when you can't as a regular user, 
and that running alsaconf (as root) fixes it then?

If you see them as root but not as a normal user, it's a permissions 
problem.

Just to check, your user is in the audio group, right?  (I expect so 
since otherwise you'd likely have problems even after running alsaconf as 
root, since it's going to assume that.)

What's the permissions on all the components in the /dev/snd dir?  Check 
both before and after running alsaconf, to see if there's a change, 
either in devices listed or in permissions.

Here's what I have here:

ls -l /dev/snd
total 0
crw-rw---- 1 root audio 116,  0 2009-06-30 14:05 controlC0
crw-rw---- 1 root audio 116, 24 2009-06-30 14:05 pcmC0D0c
crw-rw---- 1 root audio 116, 16 2009-07-01 07:26 pcmC0D0p
crw-rw---- 1 root audio 116, 25 2009-06-30 14:05 pcmC0D1c
crw-rw---- 1 root audio 116,  1 2009-06-30 14:05 seq
crw-rw---- 1 root audio 116, 33 2009-06-30 14:05 timer

If you're not seeing similar, and/or the group isn't audio, and/or you're 
not seeing 660 perms (read/write on group is what we're after), then 
that's likely the problem...

Years ago, there was a pam-console module that could screw up 
permissions.  The idea back then was to set the owner to the actual 
logged-in user and only allow them access.  The reasoning went something 
like this: Consider the scenario of an office, with a multi-user system, 
with one user logged in locally and perhaps others logged in remotely, 
from other areas of the office.  Now, imagine all those users are in the 
audio group.  Now, imagine some wiseguy at the other end of the office 
logging in, turning the sound volume up, and having it play... say a 
nasty fart... or a porno soundtrack, or something.  The poor user 
actually logged in at the console would have no idea... but be extremely 
embarrassed!

Unfortunately that didn't work so well, because for various reasons, X 
sessions weren't always counted as logins, so it was quite possible to 
have someone logged into X but not at the text console, and not have 
sound permissions as a result.  Combine this with the fact that multiple-
user logins, at least at the same time (and remote) are far less common 
these days, and it was a huge hassle for very little gain.  Many people 
ended up either setting pam-console permissions for that sort of stuff to 
660 audio group or 666 world writable, if they could figure out pam-
console's settings to do so, or having to jump thru hoops like keeping a 
text console logged in, in ordered to have sound in X.

pam-console has been obsolete on Gentoo for years now, I think, but 
perhaps you are still running it?  Unlikely, since I don't even see it 
listed as available any more, but one never knows.

Alternatively, consolekit is supposed to be the modern version of pam-
console, I think.  X requires it, and I have it installed, but I haven't 
the foggiest how it works and its config is 100% default here.  However, 
it's possible there's a similar issue with it.  Unfortunately, as I said, 
I haven't the foggiest on it.

Then there's udev.  At least with the ~arch version I have
installed (udev-141-r1), its permission rules for alsa seem to be in 
/lib64/udev/rules.d/40-alsa.rules .  That doesn't appear to be 
CONFIG_PROTECTed by default, so any changes made to the rules there will 
be overwritten when you update udev.  FWIW, here's the file as I have it:

# do not edit this file, it will be overwritten on update

SUBSYSTEM=="sound",             GROUP="audio"
KERNEL=="controlC[0-9]*",       NAME="snd/%k"
KERNEL=="hwC[D0-9]*",           NAME="snd/%k"
KERNEL=="pcmC[D0-9cp]*",        NAME="snd/%k"
KERNEL=="midiC[D0-9]*",         NAME="snd/%k"
KERNEL=="timer",                NAME="snd/%k"
KERNEL=="seq",                  NAME="snd/%k"
KERNEL=="mixer0",               SYMLINK+="mixer"

As you can see, it's set to create all devices in the audio group, so 
that's what you should see, unless something strange is going on.  FWIW, 
you'd put any changes in a file in /etc/udev/rules.d, which should be 
CONFIG_PROTECTed.

Of course you may not be running udev, preferring a static /dev.  In that 
case, changes you make to the device permissions should remain.

Depending on your config, you may also have some devices copied into dev 
from a state dir, as part of the udev setup.  I disabled that right away 
as udev was working fine on its own and I didn't want anything screwing 
up its work, but Gentoo was using a state tarball by default for some 
time, and for all I know, still is.  But I think that's part of 
baselayout/openrc, and I've been on baselayout-2/openrc for long enough 
now I've quite forgotten how baselayout-1 worked, so you'll have to find 
that stuff on your own if you're still using it (which you likely are if 
you're on stable).

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman