Description of problem: After an update of a laptop to FC4 now I see from everything which can complain (these particular messages were produced by ogg123): ALSA lib conf.c:1578:(snd_config_load1) _toplevel_:51:23:No such file or directory ALSA lib conf.c:2823:(snd_config_hook_load) /etc/alsa/cards/aliases.conf may be old or corrupted: consider to remove or fix it ALSA lib conf.c:2686:(snd_config_hooks_call) function snd_config_hook_load returned error: No such file or directory ALSA lib pcm.c:1959:(snd_pcm_open_conf) Invalid type for PCM default definition (id: default, value: cards.pcm.default) and after I got an information, or a complaint, that obsolete OSS interface is used. The second "No such file or directory" refers most likely to dmix.conf or to dsnoop.conf in /etc/alsa/pcm/ directory. Such files are indeed not there but only {dmix,dsnoop}.template. What "_toplevel_:51:23" is about I really do not know. /etc/alsa/cards/aliases.conf is exactly as was installed by 'alsa-lib'. It does have these lines at the bottom: <confdir:pcm/default.conf> <confdir:pcm/dmix.conf> <confdir:pcm/dsnoop.conf> and /etc/alsa/pcm/default.conf does exist. I do have a sound but 'timidity', for example, used to work with '-Os'. Now with such option it prints: (id: default, value: cards.pcm.default) Can't open pcm device 'default'. Couldn't open ALSA pcm device (`s') and it needs '-Od' to play something. I do have a populated directory /dev/snd/ with twelve entries in it and what I can gather from /proc/asound/ looks sane. In particular this in /proc/asound/devices: 1: : sequencer 20: [0- 4]: digital audio playback 27: [0- 3]: digital audio capture 26: [0- 2]: digital audio capture 25: [0- 1]: digital audio capture 16: [0- 0]: digital audio playback 24: [0- 0]: digital audio capture 0: [0- 0]: ctl 33: : timer 48: [1- 0]: digital audio playback 56: [1- 0]: digital audio capture 32: [1- 0]: ctl This is in /etc/asound.conf # Generated by system-config-soundcard, do not edit by hand defaults.pcm.card 0 defaults.ctl.card 0 2.6.12-1.1456_FC4 kernel with snd-intel8x0 sound card driver. Version-Release number of selected component (if applicable): alsa-lib-1.0.9rf-2.FC4 How reproducible: always
dmix.conf and dsnoop.conf should be created during login, when user is getting the console lock. Do you use a regular user or the root?
> dmix.conf and dsnoop.conf should be created during login ... Hm ... > Do you use a regular user or the root? Tried both, although normally I do not run things as root. Messages quoted were from a non-root login. OTOH I tried a regular user login once again and this time I do see new files in /etc/alsa/pcm: -rw-r--r-- 1 root wheel 0 Sep 25 11:51 dsnoop.conf.lock -rw-r--r-- 1 root wheel 1117 Sep 25 11:51 dsnoop.conf -rw-r--r-- 1 root wheel 0 Sep 25 11:51 dmix.conf.lock -rw-r--r-- 1 root wheel 1126 Sep 25 11:51 dmix.conf What made a difference this time I have no idea. At some moment udev seemed to have sudden troubles with detecting sound hardware on a startup but then there was no /dev/snd/ directory at all. OTOH relogging as 'root' removed dsnoop.conf and dmix.conf again. Does that mean that if OSS interfaces are absent then root does not have a sound?
If you log in as a regular user (and files dmix.conf and dsnoop.conf exist), does the sound work?
Sound does work either way. The difference is that if those files were not created, for reasons which still elude me, then you can only use OSS devices and otherwise ALSA devices are recognized (this includes dmix with sound from multiple sources). I tried to recreate situations when dmix.conf and dsnoop.conf are _not_ created on regular logins and, of course, now I have troubles with that. There is a distinct possiblity that this was courtesy of a demented system-config-display which likes to break silently my xorg.conf. Side effects of that seem to include a messed up BIOS too (probably means that BIOS is not too healthy, or at least brittle, and this is not a big surprise). See bug #169204 for system-config-display issues.
dmix.conf and dsnoop.conf are created when you log in as regular user and they aren't created if you log in as root. If you want to use the soundcard as root you have to use only HW device. You can do it this way - write these lines to /etc/asound.conf: pcm.!default { type hw card 0 } ctl.!default { type hw card 0 }
> If you want to use the soundcard as root ... Yes, but in some circumstances I had the same problem on a non-root accout too (as I wrote in comment #2). The trouble is that I do not know how to reproduce a sequence of events which led to that. Especially now when the laptop in question is far away and will be not back for quite a while. Adding lines you suggest seems like a reasonable fall-back position.