sean <tech.j...@myfairpoint.net> posted 4a4b6572.8000...@myfairpoint.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
