Hello, I've reported the bug to Debian with all the details (with dmesg + alsa-info.sh info attached) under http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661335 but in a nutshell: the following works under 3.1.8 but not anymore under 3.2.4 (and neither 3.2.6 or even 3.3.0-rc6): # speaker-test -D hdmi:CARD=PCH,DEV=1 -c2 whereas the following always works: # speaker-test -D front:CARD=PCH,DEV=0 -c2 I've already multiple reboots back and forth between the multiple kernel versions, so I don't think it's due to my configuration. Let me know if you need more information. Thanks, Eric
Please attach alsa-info.sh on both working and non-working versions to this bugzilla.
Created attachment 72643 [details] good alsa-info (3.1.8) from http://bugs.debian.org/661335
Created attachment 72644 [details] bad alsa-info (3.2.6) from http://bugs.debian.org/661335
Created attachment 72645 [details] bad alsa-info (3.3-rc6) from http://bugs.debian.org/661335
Created attachment 72646 [details] boot log for 3.3-rc6, from http://bugs.debian.org/661335
Created attachment 72647 [details] boot log for 3.1.8, from http://bugs.debian.org/661335
In the recent kernel, the driver probes all possible HDMI pins. And, in your case, the secondary HDMI might correspond to the actual output. Try either % speaker-test -Dhdmi:CARD=PCH,DEV=3 -c2 or % speaker-test -Dhdmi:CARD=PCH,DEV=7 -c2 It's basically a problem of BIOS. BIOS set the pins as active outputs, so the driver simply exposes all of these.
It worked in 3.1.y, though. How does 3.1.y know which output to expose, and would it make sense for the kernel driver to number outputs so that one comes first?
In the earlier kernel, the driver supported only a single pin and it coincidentally pointed to the right one. So, it's no regression in the kernel driver. It's just a side-effect by allowing more thing that should have been done.
Ah, so the pin it chose was just as often wrong as right, and the change to probe all of them uses some different ordering heuristic that puts the right one first for a different population of the same size?
Yes (suppose that the comment 7 really hits the output). A fix in the driver side would be to override the BIOS setup by checking PCI or codec SSID. Or, BIOS might be correct -- I don't know whether any other output is available on this machine. At least, BIOS shows there are two active HDMI output pins, and one dead HDMI output pin.
Created attachment 74521 [details] More tests under 3.4.4 with different hdmi pins
Hello, I'm not sure to have understood everything you've written, but what does it mean practically would be my main question? The problem is still there under 3.4.4 (I updated the kernel version of this report, I hope that was correct behavior) and I'm still stuck on 3.1... Based on the comment #7, I've done some more tests (attached), let me know if I can do more to help fix this issue. Thanks, Eric
The output in comment #12 is in German (for the future, exporting LC_ALL=C before running tests can save time). If I understand it correctly, there are two HDMI outputs, and I can't say if either of them works and where the output goes (of course the messages to stdout don't make such things clear). Can you spell it out for me? Does the first HDMI output work ok? Note that outputs are enumerated before jack-detection can meaningfully happen so if the 0th output doesn't happen to be the right one, probably the easiest place to fix apps to use the appropriate output instead would be in userspace.
Hello, I apologize, I'm normally using Linux in English and didn't realize that. Actually, both HDMI devices listed by aplay -L seemingly are OK but no sound comes out. With Kernel 3.1, the result is the same but sound comes out of DEV=0 (but not from DEV=1). When I then count up from 2 to 10, device 2 and 3 have just the error "Device open error: -2,File or directory not found" whereas 4 to 10 are bringing more errors (in English mostly, "Datei oder Verzeichnis nicht gefunden" means just "File or Directory not found"). Hope this was what you needed, and sorry again. Eric
Created attachment 78091 [details] alsa-info.sh outputs under kernel 3.1, 3.5 and difference between both. Beside the fact that I don't really understand what it exactly means, I find interesting to see the much higher number of controls available under 3.5 compared to 3.1 (55 vs. 43) and especially the 2 new controls: Control.43: name="HDMI/DP,pcm=3 Jack", index=0, device=0 Control.49: name="HDMI/DP,pcm=7 Jack", index=0, device=0 Should I perhaps do something with those controls under 3.5, that I didn't have to do under 3.1? The 2nd interesting thing is to see that dmesg under 3.5 doesn't have anymore all the HDMI messages. Cleaned up kernel messaging or sign of a problem?
New tests done under kernel 3.5 - issue still there (see previous attachement)
As already mentioned, BIOS on your machine provides three outputs. In the earlier kernel, the driver didn't take all three but only one, and it casually worked. In the recent kernel, however, all three outputs are taken into account, thus your formerly working device is shifted as the result. That's the reason. You'll have to specify the exact device number to your application, or fix the pin setup.
Hello Takashi, this is where I stop understanding you: 1. I have tried what you told me, with the DEV variable going from 0 to 10 (see attachement "More tests under 3.4.4 with different hdmi pins") with a completely negative result. 2. You speak of one respectively three outputs whereas the output of 'aplay -l' (APLAY section in the alsa-info output) between 3.1 and 3.5 didn't change and was 4, so I would really appreciate if you could tell me to which 3 devices you refer (I'm assuming we're not talking about device files under /dev/snd as they're exactly the same). 3. I haven't yet tried to reconfigure anything as I'm directly accessing the devices with the test command 'speaker-test' and even this doesn't work. I hope that it's correct that my tests are not dependent on any application configuration, and that they are conclusive in terms of results. I would hope so as it is part of the package 'alsa-utils' that seems to come directly from the ALSA project. If you have a better alternative to do conclusive tests, please let me know. 4. Looking more into it, I think there was some confusion done (and I apologize for this) between the output of 'aplay -L' with HDMI devices 0 and 1 and the output of 'aplay -l' with devices 3 and 7, HDMI 0 resp. 1. Please take this into consideration in your next answer. You see, I'm doing my best to follow your instructions and understand what you're telling me, but my knowledge is limited and it would be really nice if you could be slightly more exhaustive in your instructions that I better understand what you are trying to tell me. Thanks in advance, Eric
Hi Eric, Eric L wrote: > I have tried what you told me, with the DEV variable going from 0 to 10 (see > attachement "More tests under 3.4.4 with different hdmi pins") with a > completely negative result. Any news? What kernel are you using these days, and does it still give no sound regardless of which output you choose? Thanks for your patience, Jonathan
No changes still my last comment, I'm still on 3.1.8 and HDMI sound doesn't work from 3.2 to 3.5 inclusive (3.6 is not yet packaged in Debian). Are my questions in comment #19 so stupid that I don't even get an answer to them? Looking back, some answers to comment #16 would also be interesting.
Hello, tested today 3.6 and "speaker-test -Dhdmi:CARD=PCH,DEV=1 -c2" is giving again a sound! To be sure, I tested again under 3.5 and it still doesn't work (hence no config change on my side, just a kernel change). # uname -a Linux hdvdr 3.6-trunk-amd64 #1 SMP Debian 3.6.9-1~experimental.1 x86_64 GNU/Linux So, do we call it a day, or is there any chance to backport the relevant change? Eric
(In reply to comment #22) > tested today 3.6 and "speaker-test -Dhdmi:CARD=PCH,DEV=1 -c2" is giving again > a > sound! To be sure, I tested again under 3.5 and it still doesn't work (hence > no > config change on my side, just a kernel change). > > # uname -a > Linux hdvdr 3.6-trunk-amd64 #1 SMP Debian 3.6.9-1~experimental.1 x86_64 > GNU/Linux Yay, thanks for the update. > So, do we call it a day, or is there any chance to backport the relevant > change? Assuming the patch is safe, I think the Debian folks would be happy to include it in wheezy and propose it for inclusion in kernel.org's 3.2.y. Of course there's the small matter of finding which patch it is first... :) Thanks for the hints. If you have time for a reverse bisect, that could take the mystery away. gratefully, Jonathan