[gentoo-amd64] Alsa Config keeps disappearing

[gentoo-amd64] Alsa Config keeps disappearing

[sean]

After a system startup I have to rerun alsaconfig to get sound working.

Is anyone able to give me any clues on how to track down why the config
needs to be redone after a startup?

		Thanks
		Sean

Re: [gentoo-amd64] Alsa Config keeps disappearing

[Saphirus Sage]

sean wrote:
> After a system startup I have to rerun alsaconfig to get sound working.
>
> Is anyone able to give me any clues on how to track down why the config
> needs to be redone after a startup?
>
> 		Thanks
> 		Sean
>
>   
The exact same thing has been happening to me, and I have an alsa.conf
file in both /etc/modprobe.d and /etc/modules.d so I don't know what's
going on.

Re: [gentoo-amd64] Alsa Config keeps disappearing

[Volker Armin Hemmann]

On Montag 29 Juni 2009, sean wrote:
> After a system startup I have to rerun alsaconfig to get sound working.
>
> Is anyone able to give me any clues on how to track down why the config
> needs to be redone after a startup?
>
> 		Thanks
> 		Sean

what do you mean with 'Get working'? And why do you have to redo it? Is the 
config gone after a boot? Or do you just forgot to add alsa to default?

Re: [gentoo-amd64] Alsa Config keeps disappearing

[sean]

Saphirus Sage wrote:

>>
>>   
> The exact same thing has been happening to me, and I have an alsa.conf
> file in both /etc/modprobe.d and /etc/modules.d so I don't know what's
> going on.
> 

There is a strange comfort knowing that I am not the only one.

Re: [gentoo-amd64] Alsa Config keeps disappearing

[sean]

Volker Armin Hemmann wrote:
> On Montag 29 Juni 2009, sean wrote:
>> After a system startup I have to rerun alsaconfig to get sound working.
>>
>> Is anyone able to give me any clues on how to track down why the config
>> needs to be redone after a startup?
>>
>> 		Thanks
>> 		Sean
> 
> what do you mean with 'Get working'? And why do you have to redo it? Is the 
> config gone after a boot? Or do you just forgot to add alsa to default?
> 
> 

Alsa is started at boot.

For example, you wanted to listen to a CD or play a DVD, there is no
sound. I have to run alsaconfig again to get sound working again.
Once that is done, the CD or DVD will play with sound.

I use xine for both CD and DVD, and a xine-out.wav is generated if
alsaconig has not been run again after a system startup.

Re: [gentoo-amd64] Alsa Config keeps disappearing

[Volker Armin Hemmann]

On Montag 29 Juni 2009, sean wrote:
> Volker Armin Hemmann wrote:
> > On Montag 29 Juni 2009, sean wrote:
> >> After a system startup I have to rerun alsaconfig to get sound working.
> >>
> >> Is anyone able to give me any clues on how to track down why the config
> >> needs to be redone after a startup?
> >>
> >> 		Thanks
> >> 		Sean
> >
> > what do you mean with 'Get working'? And why do you have to redo it? Is
> > the config gone after a boot? Or do you just forgot to add alsa to
> > default?
>
> Alsa is started at boot.
>
> For example, you wanted to listen to a CD or play a DVD, there is no
> sound. I have to run alsaconfig again to get sound working again.
> Once that is done, the CD or DVD will play with sound.
>
> I use xine for both CD and DVD, and a xine-out.wav is generated if
> alsaconig has not been run again after a system startup.

you know that channels are muted by default and unmute them, do you?

Re: [gentoo-amd64] Alsa Config keeps disappearing

[sean]

Volker Armin Hemmann wrote:

> 
> you know that channels are muted by default and unmute them, do you?
> 
> 

On every boot they are muted at system startup?
I do not recall that ever being the case.

Re: [gentoo-amd64] Alsa Config keeps disappearing

[sean]

sean wrote:

> 
> I use xine for both CD and DVD, and a xine-out.wav is generated if
> alsaconig has not been run again after a system startup.
> 
> 

Additional note, that xine-out.wav is a file of the sound that should
have been played over the speakers.

Re: [gentoo-amd64] Alsa Config keeps disappearing

[Bob Sanders]

sean, mused, then expounded:
> After a system startup I have to rerun alsaconfig to get sound working.
> 
> Is anyone able to give me any clues on how to track down why the config
> needs to be redone after a startup?
>

Have you tried -

   alsactl store 

after the card has been configured, before rebooting?

Bob
-  

Re: [gentoo-amd64] Alsa Config keeps disappearing

[Paul Hartman]

On Mon, Jun 29, 2009 at 3:26 PM, sean<tech.junk@myfairpoint.net> wrote:
> After a system startup I have to rerun alsaconfig to get sound working.
>
> Is anyone able to give me any clues on how to track down why the config
> needs to be redone after a startup?

Do you have RESTORE_ON_START="yes" in your /etc/conf.d/alsasound file?

Re: [gentoo-amd64] Alsa Config keeps disappearing

[Paul Hartman]

On Mon, Jun 29, 2009 at 4:38 PM, Paul
Hartman<paul.hartman+gentoo@gmail.com> wrote:
> On Mon, Jun 29, 2009 at 3:26 PM, sean<tech.junk@myfairpoint.net> wrote:
>> After a system startup I have to rerun alsaconfig to get sound working.
>>
>> Is anyone able to give me any clues on how to track down why the config
>> needs to be redone after a startup?
>
> Do you have RESTORE_ON_START="yes" in your /etc/conf.d/alsasound file?

As well as SAVE_ON_STOP="yes" of course...

Re: [gentoo-amd64] Alsa Config keeps disappearing

[Volker Armin Hemmann]

On Montag 29 Juni 2009, sean wrote:
> Volker Armin Hemmann wrote:
> > you know that channels are muted by default and unmute them, do you?
>
> On every boot they are muted at system startup?
> I do not recall that ever being the case.

maybe. If you have set them up that way at some point. Look for a file called 
'asound.state'.

[gentoo-amd64] Re: Alsa Config keeps disappearing

[Duncan]

sean <tech.junk@myfairpoint.net> posted 4A492614.1050603@myfairpoint.net,
excerpted below, on  Mon, 29 Jun 2009 16:37:40 -0400:

> I use xine for both CD and DVD, and a xine-out.wav is generated if
> alsaconig has not been run again after a system startup.

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.

But running the config loads the modules, which apparently are NOT auto-
loaded by the alsa service or whatever you have running at start to bring 
back sound -- that's assuming that you DO have something running to load 
sound at start.

FWIW, I've never had an issue of that nature here.  For quite some time I 
didn't run the alsa service at boot, since I only used sound in KDE, and 
KDE would start it when I started KDE.  However, when I switched to an 
mpd based music system, I switched to starting sound at boot, and it 
"just worked".

BUT, my kernel policy has for YEARS been to build-in everything possible 
that I use enough to keep loaded.  Stuff like the floppy and loopback 
drivers don't get built-in, as I very seldom use them and thus might as 
well not load them unless I DO use them.  But all my sound drivers get 
built-in, because if I'm loading them at boot and never unloading them, I 
might as well.  So presuming the problem is what I think it is, I 
couldn't have it here, because the sound drivers are built-in, not loaded 
as modules, so they're always loaded.

Of course, that can get a bit complicated for those drivers that need 
parameters fed to them at load.  Loading the modules is then easiest.  
However, most of them can have the parameters fed to the kernel directly 
on the kernel command line, as fed to it from grub (or with newer 
kernels, 2.6.29 maybe??, from the built-in kernel commandline option, 
which sure simplified /my/ grub kernel line!).  The problem then is 
finding the documentation telling you exactly what form to use on the 
kernel commandline, since the options take a bit different form there, 
including the driver name, etc, as it's otherwise not obvious what they 
refer to.  But in most cases it can work, you just have to find out 
exactly what to feed the kernel commandline.

So that's what I'd suggest.  If your sound card drivers do NOT require 
driver commandline options, build them in.  If they DO, it's a bit more 
complicated as you'll have to find documentation covering the exact 
format of the kernel commandline options to feed, but look around in the 
kernel documentation dir and do some googling and see what comes up.  If 
you can find what to feed the kernel, do so, build-in the drivers, and 
that will hopefully eliminate the issue.  Of course, this assumes that 
you are loading the drivers at boot and not unloading them, so building 
in the drivers doesn't increase the running size of the kernel 
uselessly.  But I expect that's the case for the folks having the problem 
here, or they'd already be used to loading and unloading their sound 
drivers as needed and thus wouldn't be having the problem with the 
failure of the automatic system to load them.

-- 
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

Re: [gentoo-amd64] Alsa Config keeps disappearing

[sean]

Bob Sanders wrote:
> sean, mused, then expounded:
>> After a system startup I have to rerun alsaconfig to get sound working.
>>
>> Is anyone able to give me any clues on how to track down why the config
>> needs to be redone after a startup?
>>
> 
> Have you tried -
> 
>    alsactl store 
> 
> after the card has been configured, before rebooting?
> 
> Bob
> -  
> 
> 

Just applied the command.

Re: [gentoo-amd64] Alsa Config keeps disappearing

[sean]

Paul Hartman wrote:
> On Mon, Jun 29, 2009 at 3:26 PM, sean<tech.junk@myfairpoint.net> wrote:
>> After a system startup I have to rerun alsaconfig to get sound working.
>>
>> Is anyone able to give me any clues on how to track down why the config
>> needs to be redone after a startup?
> 
> Do you have RESTORE_ON_START="yes" in your /etc/conf.d/alsasound file?
> 
> 

yes, it is already set as such

Re: [gentoo-amd64] Alsa Config keeps disappearing

[sean]

Paul Hartman wrote:
> On Mon, Jun 29, 2009 at 4:38 PM, Paul
> Hartman<paul.hartman+gentoo@gmail.com> wrote:
>> On Mon, Jun 29, 2009 at 3:26 PM, sean<tech.junk@myfairpoint.net> wrote:
>>> After a system startup I have to rerun alsaconfig to get sound working.
>>>
>>> Is anyone able to give me any clues on how to track down why the config
>>> needs to be redone after a startup?
>> Do you have RESTORE_ON_START="yes" in your /etc/conf.d/alsasound file?
> 
> As well as SAVE_ON_STOP="yes" of course...
> 
> 

yes, already set as such

Re: [gentoo-amd64] Re: Alsa Config keeps disappearing

[sean]

Duncan wrote:
> 
> 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.


> 
> But running the config loads the modules, which apparently are NOT auto-
> loaded by the alsa service or whatever you have running at start to bring 
> back sound -- that's assuming that you DO have something running to load 
> sound at start.

Alsa is set to run on boot, and "save on top" as in the Gentoo
instructions is set.
If I try to add it to the boot up I get the message that it is already
loaded.

> 
> FWIW, I've never had an issue of that nature here. 

I have not had this issue before either, this started some time ago, now
 out of frustration I am trying to figure out why. It use to work fine
on this system.


> 
> BUT, my kernel policy has for YEARS been to build-in everything possible 
> that I use enough to keep loaded.  

I build alsa as modules since the instructions recommend that it is the
best method.

[gentoo-amd64] Re: Alsa Config keeps disappearing

[Duncan]

sean <tech.junk@myfairpoint.net> posted 4A4B6572.8000308@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

Re: [gentoo-amd64] Re: Alsa Config keeps disappearing

[sean]

Duncan wrote:
> So you're saying that it only happens as a regular user? 
No, it happens exactly the same even if logged in as root.
I just restarted and tested.

> Just to check, your user is in the audio group, right?  
yes

> 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


Mine before running alsaconf

 ls -l /dev/snd
total 0
crw-rw---- 1 root audio 116, 4 2009-07-01 07:35 controlC0
crw-rw---- 1 root audio 116, 8 2009-07-01 07:35 controlC1
crw-rw---- 1 root audio 116, 3 2009-07-01 07:35 pcmC0D0c
crw-rw---- 1 root audio 116, 7 2009-07-01 07:35 pcmC1D0c
crw-rw---- 1 root audio 116, 6 2009-07-01 07:35 pcmC1D0p
crw-rw---- 1 root audio 116, 5 2009-07-01 07:35 pcmC1D1c
crw-rw---- 1 root audio 116, 9 2009-07-01 07:35 seq
crw-rw---- 1 root audio 116, 2 2009-07-01 07:35 timer

Mine after running alsaconf
ls -l /dev/snd
total 0
crw-rw---- 1 root audio 116, 6 2009-07-01 11:39 controlC0
crw-rw---- 1 root audio 116, 5 2009-07-01 11:39 pcmC0D0c
crw-rw---- 1 root audio 116, 4 2009-07-01 11:39 pcmC0D0p
crw-rw---- 1 root audio 116, 3 2009-07-01 11:39 pcmC0D1c
crw-rw---- 1 root audio 116, 7 2009-07-01 11:39 seq
crw-rw---- 1 root audio 116, 2 2009-07-01 11:39 timer

There is some differences. Less entries, and notice the time.
I had just restarted the system to cause the problem.
I did each command just a few minutes apart, the first one however shows
a morning time, this is when it does not work, and the second shows the
correct time, after running alsaconf and it is working.
I am not sure what to make of it yet.


 > pam-console has been obsolete on Gentoo for years now, I think, but
> perhaps you are still running it?  
no, i have not installed it, mainly such things are default.

 > 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"

Mine,
/lib64/udev/rules.d/40-alsa.rules
# 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"

Seems to match yours.

[gentoo-amd64] Re: Alsa Config keeps disappearing

[Duncan]

sean <tech.junk@myfairpoint.net> posted 4A4B858E.6050202@myfairpoint.net,
excerpted below, on  Wed, 01 Jul 2009 11:49:34 -0400:

>> So you're saying that it only happens as a regular user?
> No, it happens exactly the same even if logged in as root. I just
> restarted and tested.

Well, that shoots down the bad permissions theory, upon which most of the 
rest of the post was based.  But maybe we can salvage something from it...

> Mine before running alsaconf
> 
>  ls -l /dev/snd
> total 0
> crw-rw---- 1 root audio 116, 4 2009-07-01 07:35 controlC0
> crw-rw---- 1 root audio 116, 8 2009-07-01 07:35 controlC1
> crw-rw---- 1 root audio 116, 3 2009-07-01 07:35 pcmC0D0c
> crw-rw---- 1 root audio 116, 7 2009-07-01 07:35 pcmC1D0c
> crw-rw---- 1 root audio 116, 6 2009-07-01 07:35 pcmC1D0p
> crw-rw---- 1 root audio 116, 5 2009-07-01 07:35 pcmC1D1c
> crw-rw---- 1 root audio 116, 9 2009-07-01 07:35 seq
> crw-rw---- 1 root audio 116, 2 2009-07-01 07:35 timer
> 
> Mine after running alsaconf
> ls -l /dev/snd
> total 0
> crw-rw---- 1 root audio 116, 6 2009-07-01 11:39 controlC0
> crw-rw---- 1 root audio 116, 5 2009-07-01 11:39 pcmC0D0c
> crw-rw---- 1 root audio 116, 4 2009-07-01 11:39 pcmC0D0p
> crw-rw---- 1 root audio 116, 3 2009-07-01 11:39 pcmC0D1c
> crw-rw---- 1 root audio 116, 7 2009-07-01 11:39 seq
> crw-rw---- 1 root audio 116, 2 2009-07-01 11:39 timer
> 
> There is some differences. Less entries, and notice the time. I had just
> restarted the system to cause the problem. I did each command just a few
> minutes apart, the first one however shows a morning time, this is when
> it does not work, and the second shows the correct time, after running
> alsaconf and it is working. I am not sure what to make of it yet.

You had /just/ restarted the system... so that morning time is from 
BEFORE you restarted??

Hmm...  Maybe it's running the alsa service before clock.  Do you happen 
to be running the system hardware clock (BIOS) at OTHER than UTC, at, 
say, EDT, which is four hours different?  That would explain the time 
difference, yielding a couple minute interval between the two runs.

That's... interesting... and I'd probably look at reordering the services 
so clock starts first and doesn't give you the time difference there, but 
I don't /think/ it should have anything to do with the alsa problem we're 
dealing with.

Meanwhile, the differing number of entries does reinforce my idea that 
there's something wrong with the drivers, tho apparently not the modules, 
per se, but with how they're configured at boot vs after you run 
alsaconf.  I'll have to look at the alsaconf script a bit, and compare it 
to the alsa service, to see if I can figure out what's missing at boot.  
But I'm getting sleepy now, as this is normally the time I go to bed. (US/
AZ but I sleep days.)  So I'll have to look at it again later.

Meanwhile, if anyone else wants a go, have at it! =:^)

-- 
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

Re: [gentoo-amd64] Re: Alsa Config keeps disappearing

[David Fellows]

On Wed, 01 Jul 2009 11:49:34 -0400 
sean wrote -
> Duncan wrote:
> > So you're saying that it only happens as a regular user? 
> No, it happens exactly the same even if logged in as root.
> I just restarted and tested.
> 
> > Just to check, your user is in the audio group, right?  
> yes
> 
> > 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
> 
> 
> Mine before running alsaconf
> 
>  ls -l /dev/snd
> total 0
> crw-rw---- 1 root audio 116, 4 2009-07-01 07:35 controlC0
> crw-rw---- 1 root audio 116, 8 2009-07-01 07:35 controlC1
> crw-rw---- 1 root audio 116, 3 2009-07-01 07:35 pcmC0D0c
> crw-rw---- 1 root audio 116, 7 2009-07-01 07:35 pcmC1D0c
> crw-rw---- 1 root audio 116, 6 2009-07-01 07:35 pcmC1D0p
> crw-rw---- 1 root audio 116, 5 2009-07-01 07:35 pcmC1D1c
> crw-rw---- 1 root audio 116, 9 2009-07-01 07:35 seq
> crw-rw---- 1 root audio 116, 2 2009-07-01 07:35 timer

The above shows that after boot alsa thinks it has 2 sound cards.
Do you actually have two?

> 
> Mine after running alsaconf
> ls -l /dev/snd
> total 0
> crw-rw---- 1 root audio 116, 6 2009-07-01 11:39 controlC0
> crw-rw---- 1 root audio 116, 5 2009-07-01 11:39 pcmC0D0c
> crw-rw---- 1 root audio 116, 4 2009-07-01 11:39 pcmC0D0p
> crw-rw---- 1 root audio 116, 3 2009-07-01 11:39 pcmC0D1c
> crw-rw---- 1 root audio 116, 7 2009-07-01 11:39 seq
> crw-rw---- 1 root audio 116, 2 2009-07-01 11:39 timer

After alsa thinks it has only one card. Furthermore, it appears that it is 
the second of your 2 cards.
alsaconf is really only intended to be run once on a new system its main 
function is to write the file /etc/modprobe.d/alsa
Secondarily it also kicks everything to reread the new parameters, etc, etc.

When I bashed my head against alsaconf 3 years ago it did a great job of 
detecting and configuring one sound card, but had no clue how to handle
a second card on the same system. I ended up hand-crafting the 
/etc/modprobe.d/alsa  file.

If you really have only one card I would  mv /etc/modprobe.d/alsa
to somewhere safe, just in case. Make sure it is gone from /etc/modprobe.
Then run alsaconf again. 

Do a diff between the saved and new /etc/modprobe.d/alsa
Also inspect /etc/modprobe.conf to see that it was updated with the contents
of the new /etc/modprobe.conf.  Check its timestamp too.
read man update-modules and consider if you need to run it. ALso check 
/etc/modules.d to see if there is any crud lying around that could be the 
source of the problem.

Try rebooting and see...


Regarding your timestamp anomaly - It looks like your hardware clock is 
keeping UTC but linux thinks that it is keeping local (eastern?) time. 
see man hwclock. Early in the boot the hw clock is read, 4 hours is 
subtracted to set linux's system clock, the  first set of files is is stamped,
then after your network is up an external time source is consulted and the 
system clock is reset +4 hours.

To set things up edit /etc/conf.d/clock
I recommend using UTC unless you  are dual booting windows,
I also recommend CLOCK_SYSTOHC="yes" to set your hardware clock to the 
current system time on shutdown.



Dave F

Re: [gentoo-amd64] Re: Alsa Config keeps disappearing

[sean]

David Fellows wrote:
>>
>>  ls -l /dev/snd
>> total 0
>> crw-rw---- 1 root audio 116, 4 2009-07-01 07:35 controlC0
>> crw-rw---- 1 root audio 116, 8 2009-07-01 07:35 controlC1
>> crw-rw---- 1 root audio 116, 3 2009-07-01 07:35 pcmC0D0c
>> crw-rw---- 1 root audio 116, 7 2009-07-01 07:35 pcmC1D0c
>> crw-rw---- 1 root audio 116, 6 2009-07-01 07:35 pcmC1D0p
>> crw-rw---- 1 root audio 116, 5 2009-07-01 07:35 pcmC1D1c
>> crw-rw---- 1 root audio 116, 9 2009-07-01 07:35 seq
>> crw-rw---- 1 root audio 116, 2 2009-07-01 07:35 timer
> 
> The above shows that after boot alsa thinks it has 2 sound cards.
> Do you actually have two?

No, one card that is built into the board.

> 
> After alsa thinks it has only one card. Furthermore, it appears that it is 
> the second of your 2 cards.


I do have a usb logitech webcam with built in mic.
Maybe it is somehow being confused as a soundcard?

I will also check out the clock settings.
Right now I am tired and heading for sleep.

Thanks Dave, Duncan, and all else who replied.
I will do some checking and let you know.

Re: [gentoo-amd64] Re: Alsa Config keeps disappearing

[Steve Herber]

I have to unplug my web cam and microphone each time I reboot my system
otherwise my mythtv system is messed up.  I am sure there is a way to configure 
udev to help keep them straight but I have not looked into it.

Does anyone know how to configure a system so I can control which device
goes to each application?

After reading some about the alsa/pulseaudio/jack/oss set of sound
software I am amazed it works as good as it does.

Thanks,

-- 
Steve Herber	herber@thing.com		work: 206-221-7262
Software Engineer, UW Medicine, IT Services	home: 425-454-2399

On Wed, 1 Jul 2009, sean wrote:

> David Fellows wrote:
>>>
>>>  ls -l /dev/snd
>>> total 0
>>> crw-rw---- 1 root audio 116, 4 2009-07-01 07:35 controlC0
>>> crw-rw---- 1 root audio 116, 8 2009-07-01 07:35 controlC1
>>> crw-rw---- 1 root audio 116, 3 2009-07-01 07:35 pcmC0D0c
>>> crw-rw---- 1 root audio 116, 7 2009-07-01 07:35 pcmC1D0c
>>> crw-rw---- 1 root audio 116, 6 2009-07-01 07:35 pcmC1D0p
>>> crw-rw---- 1 root audio 116, 5 2009-07-01 07:35 pcmC1D1c
>>> crw-rw---- 1 root audio 116, 9 2009-07-01 07:35 seq
>>> crw-rw---- 1 root audio 116, 2 2009-07-01 07:35 timer
>>
>> The above shows that after boot alsa thinks it has 2 sound cards.
>> Do you actually have two?
>
> No, one card that is built into the board.
>
>>
>> After alsa thinks it has only one card. Furthermore, it appears that it is
>> the second of your 2 cards.
>
>
> I do have a usb logitech webcam with built in mic.
> Maybe it is somehow being confused as a soundcard?
>
> I will also check out the clock settings.
> Right now I am tired and heading for sleep.
>
> Thanks Dave, Duncan, and all else who replied.
> I will do some checking and let you know.
>
>

Re: [gentoo-amd64] Re: Alsa Config keeps disappearing

[sean]

Steve Herber wrote:
> I have to unplug my web cam and microphone each time I reboot my system
> otherwise my mythtv system is messed up.  I am sure there is a way to
> configure udev to help keep them straight but I have not looked into it.
> 
> Does anyone know how to configure a system so I can control which device
> goes to each application?


Well as Steve mentioned about his problem, it appears mine is caused by
something similar.
On boot up my Quickcam camera with mic appears to be thought of as a
sound card by the system.
After three restarts without it plugged in I have had no sound problems.

So as mentioned if I play with the alsa probe file, or perhaps just move
it out of the directory it is located, this might not be a problem?

			Thanks
			Sean

Re: [gentoo-amd64] Re: Alsa Config keeps disappearing (Appears Cured)

[sean]

Thanks to all the helpful replies, and some things on my own, things
appear to be working.

As of this writing I have had three successful system starts and the
sound is now working properly on bootup.
Hopefully it will hold.
Some history below.

In the /etc/modprobe.d/alsa file I had tried specifying my motherboard
sound card as the only card. It did not work.
The USB Quickcam using snd_usb_audio always came up as the default sound
device. The cause of the problem.
I even tried to accommodate it and make it sound card two, but it still
 insisted on being default.

Here are pieces of that /etc/modprobe.d/alsa file with the current
settings that work, so far.

##  ALSA portion
alias snd-card-0 snd_intel8x0
# alias snd-card-1 snd_usb_audio
##  OSS/Free portion
alias sound-slot-0 snd_intel8x0
# alias sound-slot-1 snd_usb_audio

# Set this to the correct number of cards.
options snd cards_limit=1
# options snd cards_limit=2

As you can see I currently have the snd_usb_audio commented out, since
making it the number two card made no difference.

I noticed a file called blacklist.conf in the same directory and was
curious.I saw the following comment and began to wonder.

# Autoloading eth1394 most of the time re-orders your network
# interfaces, and with buggy kernel 2.6.21, udev persistent-net
# is not able to rename these devices, so you get eth?_rename devices
# plus an exceeded 30sec boot timeout
blacklist eth1394

So I decided to try the following added to that file
blacklist snd_usb_audio

So far, as mentioned, since I added that comment alsa has worked on
startup with the webcam plugged in, and when I tested the webcam for
sound and video using the Ekiga test callback number sound and video worked.
No other problems appear evident due to my putting these settings in place.
Can anyone see a possible problem?

Hope it helps anyone with a similar problem, and again, thanks to all
for the help.

		Sean