Description of problem: The optical audio output no longer works with kernel 3.8.1-201.fc18.x86_64. If I go back to kernel 3.7.9-205.fc18.x86_64 I can use the optical output to passthrough an AC3 soundtrack to my receiver. Version-Release number of selected component (if applicable): kernel-3.8.1-201.fc18.x86_64 How reproducible: 100% Steps to Reproduce: 1.Try to use my play-movie script which switches the pulseaudio output from HDMI (which still works) to IEC958 (which is now busted). 2.get no sound at receiver Actual results: no audio Expected results: AC3 audio playing over optical output Additional info: Here's the play-movie script I use which works on the 3.7.9 kernel: #!/bin/sh # pacmd <<'EOF' set-card-profile 0 off EOF amixer --card 0 sset IEC958 unmute mplayer -vo gl_nosw -ao alsa:device=hw=0.1 -ac hwdts,hwac3, -monitoraspect 16:9 -fs "$@" pacmd <<'EOF' set-card-profile 0 output:hdmi-stereo+input:analog-stereo EOF I'll attach the working versus busted alsa-info output.
Created attachment 707253 [details] This is alsa-info when running the working 3.7.9 kernel
Created attachment 707265 [details] This is alsa-info when running the busted 3.8.1 kernel
This may just be a renumbering of devices. I found that if I change hw=0.1 in the above script to hw=0.3 it works, but I have no idea where on earth the "3" comes from other than the fact that I saw a /dev/snd/pcmCOD3p file exists so I gave 3 a try and sound appeared. Apparently pulseaudio also has no idea where the 3 should come from either because if I try running "gnome-control-center sound" and picking Digital Output (S/PDIF) - Built-in Audio the speaker test never plays any sound. Even when I used hw=0.3 there was a long delay (4 or 5 seconds) before sound actually started, so perhaps the speaker test sound simply aren't long enough. There is certainly nothing in the output from amixer that would tell me to use a "3". It is talking about 16 if anything: Simple mixer control 'IEC958',0 Simple mixer control 'IEC958 Default PCM',0 Simple mixer control 'IEC958',16
Wups! I take it back, device 3 is the HDMI output, not the S/PDIF. I found aplay -l: zooty> aplay -l **** List of PLAYBACK Hardware Devices **** card 0: PCH [HDA Intel PCH], device 0: ALC887-VD Analog [ALC887-VD Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 1: ALC887-VD Digital [ALC887-VD Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 So I heard sound when using device 3, it was just from the wrong speakers. I really get no sound at all from S/PDIF output using the 3.8.1 kernel.
For good measure I just installed kernel-3.8.2-206.fc18.x86_64 from koji and it also does not work with S/PDIF. Identical results to 3.8.1.
send email to alsa devel mailing list when hda codec have two spdif, the driver create HDMI device instead of spdif device Node 0x11 [Pin Complex] wcaps 0x400781: Stereo Digital Control: name="SPDIF Phantom Jack", index=0, device=0 Pincap 0x00000010: OUT Pin Default 0x99430140: [Fixed] SPDIF Out at Int ATAPI Conn = ATAPI, Color = Unknown DefAssociation = 0x4, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Unsolicited: tag=00, enabled=0 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x10 Node 0x1e [Pin Complex] wcaps 0x400781: Stereo Digital Control: name="SPDIF Phantom Jack", index=1, device=0 Pincap 0x00000010: OUT Pin Default 0x01456130: [Jack] SPDIF Out at Ext Rear Conn = Optical, Color = Orange DefAssociation = 0x3, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Unsolicited: tag=00, enabled=0 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x06
This alsa-devel thread looks like it might be related: http://mailman.alsa-project.org/pipermail/alsa-devel/2013-February/059233.html I can't tell if the failure to apply the patch caused this or actually doing the patch caused it :-). I did mail the alsa devel list, but since my message was moderated don't know if it will ever show up.
Then there is this later thread fixing the previous fix :-). http://mailman.alsa-project.org/pipermail/alsa-devel/2013-February/059376.html I'm certainly confused now. I can't tell if this stuff is supposed to be working or not. I definitely see the index 16 the patch talks about, but nothing seems to be able to send sound out that control.
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel you have to subscribe to the mailing list before you send email to the list
because optical spdif node 0x1e is connnected to node 0x06 Node 0x06 [Audio Output] wcaps 0x611: Stereo Digital Converter: stream=0, channel=0 Digital: Digital category: 0x0 IEC Coding Type: 0x0 PCM: rates [0x5f0]: 32000 44100 48000 88200 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x10 [Audio Output] wcaps 0x611: Stereo Digital Control: name="IEC958 Playback Con Mask", index=16, device=0 Control: name="IEC958 Playback Pro Mask", index=16, device=0 Control: name="IEC958 Playback Default", index=16, device=0 Control: name="IEC958 Playback Switch", index=16, device=0 Control: name="IEC958 Default PCM Playback Switch", index=0, device=0 Device: name="ALC887-VD Digital", type="SPDIF", device=1 Converter: stream=0, channel=0 Digital: Digital category: 0x0 IEC Coding Type: 0x0 PCM: rates [0x5f0]: 32000 44100 48000 88200 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0
I can't quite wrap my head around the alsa-speak jargon in this new alsa-devel thread about this bug: http://mailman.alsa-project.org/pipermail/alsa-devel/2013-March/060154.html But I get the impression that patches to alsa-lib are required for this to start working again. Any chance fedora will see the required alsa-lib updates soon?
http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=f5f45589f81c46d4ca4cbbe089441a0f7ac5e197;hp=8c6da54073b2c966d9a4e137ba4d521eac92816f as your hda controller have both spdif and HDMI codec the workaround is just add index 16 to "IEC958 Playback Default" and "IEC958 Playback Switch" name "IEC958 Playback Default" + index 16 lock true preserve true value [ $AES0 $AES1 $AES2 $AES3 ] } { name "IEC958 Playback Switch" + index 16 value true
But does that mean only S/PDIF will work? I want to be able to switch back and forth between them depending on which speakers I want to use. Will I have to swap in and our different versions of the /usr/share/alsa/cards/HDA-Intel.conf file to do this?
mplayer -ao alsa:device=iec958 -ac hwdts,hwac3 mplayer -ao alsa:device=hdmi -ac hwdts,hwac3
http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/plain/Documentation/sound/alsa/HD-Audio.txt if optical spdid still does not work , you may need early patching to change pin default of node 0x11 from [Fixes] to [N/A] Pin Default 0x99430140: [Fixed] SPDIF Out at Int ATAPI Conn = ATAPI, Color = Unknown DefAssociation = 0x4, Sequence = 0x0
OK, finally got around to booting into a 3.8 kernel again and the change in comment 12 applied to /usr/share/alsa/cards/HDA-Intel.conf together with the mplayer commands in comment 14 seem to do the trick. I didn't understand comment 15 at all, but I guess it isn't necessary :-). Thanks to everyone for all the info.
*** Bug 918409 has been marked as a duplicate of this bug. ***
I confirm applying the changes in #12 fixed the problem form me and now I'm running kernel 3.10 whith SPDIF working fine Thank you Best regards Alex
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 18 kernel bugs. Fedora 18 has now been rebased to 3.11.4-101.fc18. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 19, and are still experiencing this issue, please change the version to Fedora 19. If you experience different issues, please open a new bug report for those.
The fix in comment 12 worked for me, but I don't have the motherboard that had the problem any longer, so I have no idea what the current status might be.
Okay, will close this for now.