Bug 169163 - alsa-lib - complaints and no alsa devices
alsa-lib - complaints and no alsa devices
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: alsa-lib (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Martin Stransky
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-23 16:33 EDT by Michal Jaegermann
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-05 05:51:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2005-09-23 16:33:13 EDT
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
Comment 1 Martin Stransky 2005-09-25 07:12:21 EDT
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?
Comment 2 Michal Jaegermann 2005-09-25 14:39:48 EDT
> 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?
Comment 3 Martin Stransky 2005-09-26 05:05:18 EDT
If you log in as a regular user (and files dmix.conf and dsnoop.conf exist),
does the sound work?
Comment 4 Michal Jaegermann 2005-09-26 11:12:27 EDT
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.
Comment 5 Martin Stransky 2005-10-05 05:51:40 EDT
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 }
Comment 6 Michal Jaegermann 2005-10-05 11:23:42 EDT
> 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.

Note You need to log in before you can comment on or make changes to this bug.