After compiling and booting the 2.6.30-gentoo-r1 kernel, my sound card didn't produce any sound using the emu10k1 driver. Modueles were loaded and mixer displayed as usual, only nothing could be heard. Asking Grub to boot my previous kernel - 2.6.29-r5 - instead did avoid the problem, so it's the new kernel driver. I won't have the time to do stuff like git bisections for at least a month, so if anybody has a more direct suggestion as to how to avoid this, I'd be glad to know. # lspci -s 01:0a -vv 01:0a.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07) Subsystem: Creative Labs SBLive! Player 5.1 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64 (500ns min, 5000ns max) Interrupt: pin A routed to IRQ 21 Region 0: I/O ports at b880 [size=32] Capabilities: [dc] Power Management version 1 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: EMU10K1_Audigy Kernel modules: snd-emu10k1 01:0a.1 Input device controller: Creative Labs SB Live! Game Port (rev 07) Subsystem: Creative Labs Gameport Joystick Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64 Region 0: I/O ports at bc00 [size=8] Capabilities: [dc] Power Management version 1 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: Emu10k1_gameport Kernel modules: emu10k1-gp Relevant part of emerge --info: Portage 2.2_rc33 (default/linux/x86/2008.0/desktop, gcc-4.3.3, glibc-2.10.1-r0, 2.6.29-gentoo-r5 i686) ================================================================= System uname: Linux-2.6.29-gentoo-r5-i686-Intel-R-_Pentium-R-_4_CPU_3.00GHz-with-gentoo-2.0.1
(In reply to comment #0) > After compiling and booting the 2.6.30-gentoo-r1 kernel, my sound card didn't > produce any sound using the emu10k1 driver. Modueles were loaded and mixer > displayed as usual, only nothing could be heard. Asking Grub to boot my > previous kernel - 2.6.29-r5 - instead did avoid the problem, so it's the new > kernel driver. Are you sure your mixer settings are being restored correctly? I'm asking because I had a similar problem, where sound worked perfectly under 2.6.29.x, but didn't under 2.6.30. On my machine /etc/init.d/alsasound gave the following result with kernel 2.6.30: alsasound |* Restoring Mixer Levels... alsasound |Unknown hardware: "HDA-Intel" "Realtek ALC889A" "HDA:10ec0885,1458a002,00100101" "0x1458" "0xa102" alsasound |Hardware is initialized using a guess method alsasound |/usr/share/alsa/init/default:51: control element not found alsasound |/usr/share/alsa/init/default:52: missing closing brace for format alsasound |/usr/share/alsa/init/default:52: error parsing CTL attribute alsasound |/usr/share/alsa/init/default:52: invalid rule alsasound |* Errors while restoring defaults, ignoring Moreover, I had no sound. At first I figured it must have something to do with the kernel driver, but closer inspection revelead that the mixer settings stored under 2.6.29 couldn't be loaded properly with 2.6.30 (due to ALSA change from 1.0.18a to 1.0.20), and the default was not appropriate for my setup (IEC958 being off by default). Simply setting the mixer settings manually with alsamixer and them storing them with '/etc/init.d/alsasound save' did the trick for me!
(In reply to comment #1) > Are you sure your mixer settings are being restored correctly? I'd almost answered "no" to this, as I had toyed around with the mixer for ten minutes at least before booting my old kernel. However, as I just rebooted the system with 2.6.30 to look for anything unusual in dmesg, I got sound, but only on the left channel. And indeed I did find the wave output at minimum for the right channel. So it might have been the mixer first time around as well. Adjusting Subject to reflect this. > On my machine /etc/init.d/alsasound gave the following result with kernel > 2.6.30: No such messages on my system at this second reboot. Unfortunately I don't have the rc.log from my first boot into 2.6.30 around anymore. > At first I figured it must have something to do with > the kernel driver, but closer inspection revelead that the mixer settings > stored under 2.6.29 couldn't be loaded properly with 2.6.30 (due to ALSA > change from 1.0.18a to 1.0.20), That part doesn't apply to me; I've got alsa 1.0.20 up and running for a month now. So I guess it was more likely the new kernel using a different identifier for the same device, or something like this. > Simply setting the mixer settings manually with alsamixer and them storing > them with '/etc/init.d/alsasound save' did the trick for me! Did so now, will report back upon next reboot.
(In reply to comment #2) > Did so now, will report back upon next reboot. Looks good - or rather sounds good, to be precise. Question is, how to deal with this before stabilizing the 2.6.30 sources. Is there any way I can provide additional information on this? Do you want to simply ewarn about the possibility of this bug occuring? Or is it enough that this bug report here exists, so people hitting the bug can find a solution?
(In reply to comment #3) > (In reply to comment #2) > > Did so now, will report back upon next reboot. > > Looks good - or rather sounds good, to be precise. > > Question is, how to deal with this before stabilizing the 2.6.30 sources. Is > there any way I can provide additional information on this? Do you want to > simply ewarn about the possibility of this bug occuring? Or is it enough that > this bug report here exists, so people hitting the bug can find a solution? I have no suggestions regarding your last remark, but just wanted to point out that with the change of ALSA from 1.0.18 to 1.0.20 I meant the change in the drivers in kernels 2.6.29 and 2.6.30 (do 'cat /proc/asound/version') under the two kernel versions to see what I mean).
(In reply to comment #4) > with the change of ALSA from 1.0.18 to 1.0.20 I meant the change in the > drivers in kernels 2.6.29 and 2.6.30 Ah! OK, I had been referring to the versions of packages such as alsa-lib, alsa-plugins, alsa-headers and alsa-utils. In this case, I guess the change in ALSA version in the kernel code is a likely cause for me as well. (In reply to comment #2) > Unfortunately I don't have the rc.log from my first boot into 2.6.30 around > anymore. I've been wrong. OpenRC does append to that log, not replace it. So this here should be it: * Restoring Mixer Levels... Unknown hardware: "EMU10K1" "SigmaTel STAC9708,11" "AC97a:83847608" "0x1102" "0x8061" Hardware is initialized using a guess method /usr/share/alsa/init/default:51: control element not found /usr/share/alsa/init/default:52: missing closing brace for format /usr/share/alsa/init/default:52: error parsing CTL attribute /usr/share/alsa/init/default:52: invalid rule * Errors while restoring defaults, ignoring Sounds very much like your messages from comment #1.
This always happens when the ALSA-devs think it's time to change the mixer interface of some ALSA-drivers once again (which happens quite often). I had this problem several times with my different emu10k1 cards over the last six years, so I'm quite sure there's nothing we can do to prevent such behavior.
