Takashi Iwai <tiwai <at> suse.de> writes:
It might be also the video driver side. For example, when a wrong EDID is set up in X config, the audio part also doesn't work. There were similar bug reports with the older Nvidia cihpset.
definitely - but changing driver versions does not help - tried 185.x,190.x,195.x with the same results replugging HDMI cable from receiver directly to TV or using custom EDID in xorg.conf does not help either
Of course, it can be a driver bug. How did you test exactly? A preferred way is to run like: % aplay -Dhdmi foo.wav It might be -Dhdmi:1, too, depending on the h/w.
Let's check firstly from the 2ch samples.
I was testing with speaker-test -c2 -Dhdmi ... interestingly enough alsa-driver 1.0.22 behaves differently than 1.0.21
1.0.21 - no warning message in kernel log, speaker test was switching amongst channels (like it was really playing something)
1.0.22 - warning message in kernel log [ 10.096043] ALSA hda_intel.c:694: azx_get_response timeout, switching to polling mode: last cmd=0x100f0000 speaker-test/aplay just hangs forever until ^C
in both cases neither av receiver nor tv detects any audio on HDMI
Takashi
Thanks,
Michal