Red Hat Bugzilla – Bug 385481
F8 breaks Audigy SPDIF digital sound output?
Last modified: 2007-12-03 14:38:29 EST
Description of problem: Just upgraded from F7 to F8. My Audigy (version 1) sound card will no longer put out digital sound over the SPDIF (electrical) coax jack. It worked fine just hours ago in F7. I can get analog output to work. I had to manually install a few of the pulseaudio packages, as I thought that might be causing it. I installed and poked around them, but nothing helped. alsamixer without args just shows 1 control for pulseaudio. alsamixer -c0 -V playback shows all the normal Audigy controls. If I unmute Audigy Analog/Digital Output Jack, then my digital receiver instantly says "NO AUDIO". If I mute/unmute rapidly, I can see the receiver thinking about it, flashing PCM in a different way right when I unmute it. In the past, the only thing I have had to do to get digital output working was unmute this one control. I know from experience that on my receiver PCM should not be flashing nor should it say "NO AUDIO". It seems to me that alsa or the Audigy kernel driver has changed and is spitting out something invalid over the wire. I am not sure if this bug is alsa or the kernel and would appreciate guidance. I can report it to the appropriate upstream if I had an idea of whose problem it is. Also, I suspect that perhaps it may be just a config change somewhere between F7 and F8, like a sample rate change, or something. I poked around /etc/alsa as much as I could but couldn't figure out anything useful. I suppose this won't hit many people because most would use analog output. Version-Release number of selected component (if applicable): alsa-utils-1.0.15-1.fc8 alsa-lib-devel-1.0.15-1.fc8 alsa-plugins-pulseaudio-1.0.14-5.fc8 alsa-lib-1.0.15-1.fc8 alsamixergui-0.9.0-0.3.rc1.fc8.2 pulseaudio-0.9.7-0.17.svn20071017.fc8 pulseaudio-core-libs-0.9.7-0.17.svn20071017.fc8 pulseaudio-esound-compat-0.9.7-0.17.svn20071017.fc8 pulseaudio-libs-0.9.7-0.17.svn20071017.fc8 pulseaudio-libs-glib2-0.9.7-0.17.svn20071017.fc8 pulseaudio-libs-zeroconf-0.9.7-0.17.svn20071017.fc8 pulseaudio-module-gconf-0.9.7-0.17.svn20071017.fc8 pulseaudio-module-x11-0.9.7-0.17.svn20071017.fc8 pulseaudio-utils-0.9.7-0.17.svn20071017.fc8 kernel-2.6.23.1-49.fc8 How reproducible: always Steps to Reproduce: 1. Upgrade F7 -> F8 2. reboot 3. unmute digital out in alsamixer Actual results: no sound Expected results: sound
Update: I just tested playing a DVD with dolby digital passthrough and the digital output DOES work! I used: mplayer -ac hwac3 -aid 128 dvd://1 But I still cannot get basic PCM sound to play through pulse/alsa. I have tried xmms, aplay, paplay as well as basic gnome desktop sounds. So, the problem must not be the kernel, it must be alsa or something related to it or pulseaudio.
Please test sound via. system-config-soundcard.
Ya, I was playing with that already. It shows my card and it all looks ok, but no sound comes out over digital. If I switch to analog, then "sound test" in there plays the sound ok. Default audio card shows just the 1 card (Audigy). Default PCM device shows 4 options, but I'm just leaving it on the default "ADC Capture/Standard PCM Playback", which works fine in analog. But if I switch to digital out in alsamixer then I'm back to no sound. Interesting, playing around with mplayer some more, I can get PCM digital output to work: mplayer -ao alsa:device=spdif myaudiofile.wav mplayer is obviously doing a lot of low level stuff and/or bypassing my alsa config. Perhaps this problem is as simple as something in the F8 alsa config not enabling spdif?
Maybe the problem is the new pulseaudio? Since all the non-mplayer-direct sound goes through that, if it's setting the spdif wrong or overriding the digital out option in alsamixer -c0 then that would show these symptoms.
Possibly related to: http://www.pulseaudio.org/ticket/139 ?
The more I think about it, the more this seems like a pulseaudio problem related to #139. #139 references "modification of the configuration file" to get it to work. I'm trying to figure out exactly what magic I have to do, if someone who knows pulseaudio can give a hint, that would be great. I think hacking the confs will be easier than a recompile of pa (for me at least) at this point.
You can turn off pulseaudio if you remove the first hooked (included) file (pulseaudio config) from /etc/alsa/alsa.conf.
I couldn't figure out how to just disable pulseaudio (not sure what I had to do after commenting it out of alsa.conf) so I just rpm -e'd every single pulseaudio package and rebooted. Now alsamixer shows the correct controls without any -c0 argument. But still, no audio out of the digital jack. Receiver still flashes PCM when the digital control is unmuted in alsamixer. It shows "NO DATA" when the digital control is muted. Maybe it's something to do with the default format F8 alsa is using to send down the wire? A frequency issue? I can't find where in alsa to hack such things. If I hack alsa conf files, do I have to reboot each time? Or is there a way to reload it without reboot?
Perhaps related to bug #376851 ?
Problem solved. It looks like there were some weird settings in asound.state that worked in F7 but not F8, or asound.state was corrupted. I've read elsewhere about out of range values due to stricter checking in newer alsa's. Not sure if that applies here. My fix was to edit /etc/rc.d/init.d/halt and comment out the 4 salsa lines. Then I deleted /etc/asound.state and /etc/alsa/asound.state (not sure why, but the file lived in both locations, perhaps leftover from older FC's). Reboot. Go into alsamixer and unmute the Digital Output control. Boom, instantly digital output works fine in all applications and my receiver stops flashing "PCM". Running a diff on the fresh asound.state (after a salsa -s as root), I think I see the potential culprit. See attached edited diff. That diff hinted that "IEC958 Optical Raw" control must be MUTED for SPDIF non-optical to work. I can confirm that now in alsamixer. Unmute and boom, SPDIF electrical stops working. But, I'm nearly positive I tried that before and it didn't help, but I may be wrong and that might have been the culprit for much of my testing. Still doesn't explain why F8 sound didn't work OOTB. In fact, if I unmute IEC958 Optical Raw, the sound stops playing but my receiver does NOT flash "PCM", indicating that it was not the (only) problem. Lastly, during testing I hosed then reinstated my ~/.asoundrc. Looking at it, it may be required for SPDIF on Audigy to work. I nicked it from somewhere and don't really understand it, but it looks like it may be important. I'm attaching it (the one that is working for me now). I remember ages ago having to fight with that file to make digital out work, and I recall that the most important part was forcing it into 48kHz. Perhaps someone needs to make this setting forced globally for Audigy (1) cards, if Audigy's won't work at 44.1kHz. Next I will reinstall all pulseaudio stuff and get that working. I will report back. I suppose this bug is CLOSED, unless someone wants to make life easier for Audigy 1 users and force 48k by default. Documenting of the 2 important controls might be good too, but who knows where that would go.
Created attachment 260641 [details] diff of my buggy vs fresh asound.state files Only the bottom 4 contexts appear relevant, especially the last one. Not sure how important the "inactive" options were/are.
Created attachment 260651 [details] my working ~/.asoundrc Ripped from somewhere on the net ages ago. The forcing of 48k may be critical here. Is there a good place to put this stuff globally? /etc/asound.conf?
Close this as NOTABUG, unless someone wants to tweak the default Audigy card confs to include what's required from my asoundrc, since digital output will not work at all without those settings and they won't hurt a normal-case analog output setup. I reinstalled all pulseaudio stuff and my setup is now working great with PA. PA was a red herring, it really had nothing to do with this bug. Just the "blame whatever is new" mentality. Note to others with similar bugs: look in alsa, not PA, for the bug, as it's likely there.