Dear developers ! First of all, sorry if I am reporting this at a wrong place. In case please make a note where I should report it. Since kernel 3.0 really a horde of things improved with Intel Sandy Bridge. We got proper video mode detection reading CEA blocks from EDID. Also we got proper available sound mode detection from EDID data. It is almost perfect. There is still one issue left. Despite it is reported in ELD data and despite multichannel HD LPCM audio works perfectly, HBR passthrough is not working as expected. For both DTS-HD-MA and DOLBY-TRUHD I only get static like noise coming from the speakers. The noise is different for the two formats. I tested it with two ways. Both ways are working perfectly with newer Nvidia video cards. - pre made spdif binary stream played back with aplay. This method is coming from ffmpeg developers. Testing was done according to this thread: http://www.nvnews.net/vbulletin/showthread.php?t=157347 The only difference is that for the soundcard I had to change Intel to PCH. - Also tested with xbmc media center which has an Audio Engine branch (soon to be merged mainline https://github.com/gnif) supporting passthrough of these formats and tested working great on Nvidia hardware. For both testing cases I got the same sounding static noise from speakers. Receiver shows multichannel lpcm instead of the correct format. Testing hw: Intel Sandy Bridge 2500K CPU Ubuntu Precise, with upgradeed kernel to 3.3.2 AV receiver: Onkyo TX SR606 Enclosed all relevant logs and info files Thank you for the hard work. Regards, Attila Jakosa
Created attachment 60452 [details] dmesg log
Created attachment 60453 [details] card0 codec3 info
Created attachment 60454 [details] card0 eld3 output
Created attachment 60455 [details] Xorg log
Likely we need to pass to the HDA developers.
(In reply to comment #5) > Likely we need to pass to the HDA developers. Thank you for the response. Can you do it, or can you give me a way to reach them ? Thanks.
I can confirm these HD Audio passthrough issues with 3.3.2 kernel, Alsa 1.0.25 and an Intel DH67CF motherboard
(In reply to comment #6) > (In reply to comment #5) > > Likely we need to pass to the HDA developers. > > Thank you for the response. Can you do it, or can you give me a way to reach > them ? First just want to check with the others whether they know of any developments in this area. As you are aware we are currently working on improving infoframe support and this just might be part of that. Also high-definition audio channels may need to be taken into account for our link bandwidth calculations, which it is not yet. So there is a possibility that we are simply not setting up the link correctly, as well as the possibility that the audio is not correctly piggy-backing upon the display link.
(In reply to comment #8) > (In reply to comment #6) > > (In reply to comment #5) > > > Likely we need to pass to the HDA developers. > > > > Thank you for the response. Can you do it, or can you give me a way to reach > > them ? > > First just want to check with the others whether they know of any developments > in this area. As you are aware we are currently working on improving infoframe > support and this just might be part of that. Also high-definition audio > channels may need to be taken into account for our link bandwidth calculations, > which it is not yet. So there is a possibility that we are simply not setting > up the link correctly, as well as the possibility that the audio is not > correctly piggy-backing upon the display link. I was not aware of these. Could I do something or try something so that we could start to narrow down the problem ? I wouldn't think it is a link bandwidth problem as we can have uncompressed high definition LPCM sound working with 192khz, 24bits up to 8 channels. I think none of the HBR audio formats have this kind of bandwidth need. I mean they are lossless compressed versions of the LPCM sound (If I am right) and even only with a smaller bitrate.
(I'm the original author of HBR support in HDA) Indeed, DTS-HD MA and TrueHD require exactly the same bandwidth as 192kHz 8 channel 16-bit PCM. The only difference in the HDMI data for HBR passthrough is sent as HBR Audio Stream Packets (HDMI spec 5.3.11) instead of normal Audio Sample Packets (HDMI spec 5.3.4), which differ by several bits in their header. To make that switch, the ALSA HDA driver sets AC_PINCTL_EPT_HBR bit in the pin widget control when HBR data is being output (8 channel stream with non-pcm AES flag set by the user app). Maybe intel cards need some more manual work on the DRM side so that HBR mode is being entered properly? (on nvidia it seems to be handled by the hw automatically when EPT_HBR is set) I'm assuming here that HBR passthrough doesn't work on any intel card. If it does work for some people, I guess the above is less likely to be the case. Another possibility is that the non-pcm bit is somehow lost before hdmi_setup_stream() in patch_hdmi.c is reached, so it doesn't enable HBR mode in the first place.
(In reply to comment #10) > I'm assuming here that HBR passthrough doesn't work on any intel card. If it > does work for some people, I guess the above is less likely to be the case. Looks like it's broken for all cards. On my H77 Ivy-Bridge system (most recent versions of kernel/drivers/ALSA) I am also getting only static noise when trying to pass through DTS-HD. I hope this issue is still being investigated.
I'm not aware of anything audio specific that our hw needs. One thing that's for sure is that we need to set up all the other hdmi infoframes correctly. And we've discovered tons of bugs in our code in that area recently. Please retest witht 3.5, and if that's not good enough, with drm-next (or 3.6-rc1).
Note that there is an additional bug in the ALSA land affecting HBR passthrough on intel. The CTLINDEX=x values in /usr/share/alsa/cards/HDA-Intel.conf are off when you have S/PDIF output in the same card as HDMI, which is often the case on Intel. The workaround is to bump all the CTLINDEX=x values one step up in the HDA-Intel.pcm.hdmi.foo entries, i.e. CTLINDEX=0 => CTLINDEX=1 CTLINDEX=1 => CTLINDEX=2 etc, in the /usr/share/alsa/cards/HDA-Intel.conf. However, the original reporter has confirmed that this workaround alone doesn't make it work, so there is something else wrong as well.
I have tried both 3.5 and drm-intel-testing from ~danvet/drm-intel - they are all affected by this issue. I have also tried to modify the CTLINDEX in HDA-Intel.conf. Result: Modified HDA-Intel.conf: * 2-channel PCM: OK * DTS passthrough: OK * DTS-HD passthrough: no sound at all, receiver does not show anything Original HDA-Intel.conf: * 2-channel PCM: OK * DTS passthrough: OK * DTS-HD passthrough: crackling noise, receiver shows 8 channel PCM
(In reply to comment #10) > (I'm the original author of HBR support in HDA) > > Indeed, DTS-HD MA and TrueHD require exactly the same bandwidth as 192kHz 8 > channel 16-bit PCM. The only difference in the HDMI data for HBR passthrough is > sent as HBR Audio Stream Packets (HDMI spec 5.3.11) instead of normal Audio > Sample Packets (HDMI spec 5.3.4), which differ by several bits in their header. > > To make that switch, the ALSA HDA driver sets AC_PINCTL_EPT_HBR bit in the pin > widget control when HBR data is being output (8 channel stream with non-pcm AES > flag set by the user app). > > Maybe intel cards need some more manual work on the DRM side so that HBR mode > is being entered properly? (on nvidia it seems to be handled by the hw > automatically when EPT_HBR is set) indeed, we found gpu registers didnot reflect the HBR settting correctly. i have not find the root cause yet. seems HDA verbs didnot set the pin widget control successfully. > > I'm assuming here that HBR passthrough doesn't work on any intel card. If it > does work for some people, I guess the above is less likely to be the case. > > Another possibility is that the non-pcm bit is somehow lost before > hdmi_setup_stream() in patch_hdmi.c is reached, so it doesn't enable HBR mode > in the first place.
Created attachment 66654 [details] [review] cover letter
Created attachment 66655 [details] [review] fix channel allocation order fix channel allocation order
Created attachment 66656 [details] [review] patch 2
Created attachment 66657 [details] [review] patch 3
Created attachment 66658 [details] [review] patch 1
Tested the 3 new patches. They work perfectly. I tested it with both DTS Master Audio and Dolby Tru HD streams. Also tested with speaker-test. Channel mapping was right. For HBR to be working I needed the HDA.Intel.conf file, ctlindex hack https://bugs.freedesktop.org/show_bug.cgi?id=49055#c13 to workaround the separate Alsa bug.
Tested the 3 patches (Comment 18..20) now today. Everything I tested works, includes TrueHD 7.1, DTS-HR MA 7.1/6.1/5.1, DTS 5.1, DD 5.1, PCM 2-ch, PCM 5.1. Channel mapping for 7.1 is correct. Patch was applied to clean alsa 1.0.25. Requires the CTLINDEX-update to HDA-Intel.conf. Test files played on XBMC 12.0-APLPHA2 Git:20120510 (Master branch). Ubuntu 12.04, kernel 3.2.0.26. Hardware: Asus P8H67I-Deluxe with Intel i3 2120 cpu, 4Gb RAM. (Intel Cougarpoint HD audio). HDMI to AV-receiver Denon AVR-1912.
commit 72357c78b75d39ee9e8d9fb4308957d9525aa674 Author: Wang Xingchao <xingchao.wang@intel.com> Date: Thu Sep 6 10:02:36 2012 +0800 ALSA: HDMI - Fix channel_allocation array wrong order The array channel_allocations[] is an ordered list, add function to get correct order by ca_index. Signed-off-by: Wang Xingchao <xingchao.wang@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> commit 433968da4d93a194b79da552f4ca707f979ef33b Author: Wang Xingchao <xingchao.wang@intel.com> Date: Thu Sep 6 10:02:37 2012 +0800 ALSA: HDMI - Enable HBR feature on Intel chips HDMI channel remapping apparently effects HBR packets on Intel's chips. For compressed non-PCM audio, use "straight-through" channel mapping. For uncompressed multi-channel pcm audio, use normal channel mapping. Signed-off-by: Wang Xingchao <xingchao.wang@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> commit 2d7e887cbba8272a46c42d228d3ffd9a2de04168 Author: Wang Xingchao <xingchao.wang@intel.com> Date: Thu Sep 6 10:02:38 2012 +0800 ALSA: HDMI - Setup channel mapping for non_pcm audio For HBR stream test, use straight channel mapping way. when switched back to "speaker-test -c8", even the audio infoframe is up-to-date, there should be correct channel mapping setup. Signed-off-by: Wang Xingchao <xingchao.wang@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.