In every application that I have that uses ALSA breaks upon trying to make sound. The all fail with something like: application_name_here: conf.c:3144: snd_config_iterator_first: Assertion `node->type == SND_CONFIG_TYPE_COMPOUND' failed. For example, it happens to mplayer, gaim, totem... you get the idea. Simply down grading to media-libs/alsa-lib-1.0.10 resolves the issue.
Using in-kernel or alsa-driver ?
in-kernel Linux athlon 2.6.14-gentoo-r2 #1 PREEMPT I can try 2.6.15 if you think that it make sense.
Try .15 or alsa-driver. With alsa-driver all works fine here.
Linux athlon 2.6.15-gentoo-r2 #1 PREEMPT --- don't work. P.S. btw, what is the recommended way of using ALSA: in-kernel or alsa-driver?
2.6.15.1 vanilla, in-kernel also fails. Reverting to 1.0.10 works.
I also get this problem, but only when I have an ~/.asoundrc
I'm using alsa-driver. I'll try again without ~/.asoundrc ...
I haven't done any further tests, but I noticed that this alsa version (not sure if it means anything in this context, but I'm using 2.6.15.1 kernel) seems to have automatic sound mixing which means that my dmix setup in the ~/.asoundrc is not useful anymore. Could it be that the error is a conflict between alsa's automatic dmix setup and the one in ~/.asoundrc ?
I confirm that removing my .asoundrc will resolve the issue. #8: Interesting. I've been acutally pretty disappointed in the way ALSA handles muiltiple soundcards becasue I have an Audigy 2 NX and it can be turned off/on which causes weird things to happen in ALSA. I do have dmix for my integrated sound though...
works by removing dmix from /etc/asound.conf ... but this is broking my sound setup cause that way dmix doesn't work for me ....
someone posted bug upstream https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1812
Removing my .asoundrc will resolve the issue for me as well.
i had an entry in my .asoundrc which when removed allowed soudn to work again: pcm.!default { type plug slave.pcm "nforce" } where pcm.nforce is my dmix entry. then i replace that entry with : pcm.!default { type hw card 0 } and it works fine. maybe the issue is dmix related? i dunno.
Hopefully upstream will solve the crashes for final version. I've added a warning in alsa-lib in the mean time saying that .asoundrc and asound.conf should be removed to avoid crashes.
*** Bug 122184 has been marked as a duplicate of this bug. ***
I used alsa-driver too. I think rc3 should be hard-masked. If it works for those who already installed it can always add an entrie in portage.unmask. My say.
(In reply to comment #14) > Hopefully upstream will solve the crashes for final version. > I've added a warning in alsa-lib in the mean time saying that .asoundrc and > asound.conf should be removed to avoid crashes. > I tried this but I now get blips in my audio stream without my .asoundrc. Maybe there is an unrelated problem in my system however if you need to remove .asoundrc to prevent a crash, the package should be masked.
RC3 shouldn't be hardmasked. I was thinking of having this identical issue until I discovered that now my nforce3 motherboard HAS complete hardware mixing support without any need for .asoundrc file or any dmix. Please check renaming all your asoundrc files to another (backup) name.
Just for anyone having my same configuration, reading mixer: ALC850 while sound board is NVIDIA CK8S means your config doesn't need anymore the dmix (and works fine without asoundrc).
*** Bug 122778 has been marked as a duplicate of this bug. ***
*** Bug 123006 has been marked as a duplicate of this bug. ***
So it appears to be that dmix 'breaks' alsa. E.g. dmix needs to be disabled in .asound en alsa.conf so that it can be auto used. Is it however a clean autodetection thing? I can't find anything on the alsa site concerining the emu10k1. The SB Live breathern do have hardware mixing, as do some other chips. Does this mean it's always being software mixed now?
By the way, alsa-lib-1.0.11_rc4 seems to have fixed this
