Bug 49055 - HBR sound passthrough (DTS-HS-MA, Dolby-Turuhd) not working on Intel Sandy Bridge
Summary: HBR sound passthrough (DTS-HS-MA, Dolby-Turuhd) not working on Intel Sandy Br...
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium normal
Assignee: Daniel Vetter
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-22 09:34 UTC by alanw
Modified: 2017-07-24 23:02 UTC (History)
10 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg log (48.38 KB, application/octet-stream)
2012-04-22 09:35 UTC, alanw
no flags Details
card0 codec3 info (3.04 KB, application/octet-stream)
2012-04-22 09:36 UTC, alanw
no flags Details
card0 eld3 output (1.16 KB, application/octet-stream)
2012-04-22 09:36 UTC, alanw
no flags Details
Xorg log (31.71 KB, text/x-log)
2012-04-22 09:37 UTC, alanw
no flags Details
cover letter (1.31 KB, patch)
2012-09-05 06:48 UTC, Wang Xingchao
no flags Details | Splinter Review
fix channel allocation order (1.41 KB, patch)
2012-09-05 06:49 UTC, Wang Xingchao
no flags Details | Splinter Review
patch 2 (4.30 KB, patch)
2012-09-05 06:50 UTC, Wang Xingchao
no flags Details | Splinter Review
patch 3 (1.16 KB, patch)
2012-09-05 06:50 UTC, Wang Xingchao
no flags Details | Splinter Review
patch 1 (1.41 KB, patch)
2012-09-05 06:51 UTC, Wang Xingchao
no flags Details | Splinter Review

Description alanw 2012-04-22 09:34:46 UTC
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
Comment 1 alanw 2012-04-22 09:35:17 UTC
Created attachment 60452 [details]
dmesg log
Comment 2 alanw 2012-04-22 09:36:04 UTC
Created attachment 60453 [details]
card0 codec3 info
Comment 3 alanw 2012-04-22 09:36:45 UTC
Created attachment 60454 [details]
card0 eld3 output
Comment 4 alanw 2012-04-22 09:37:35 UTC
Created attachment 60455 [details]
Xorg log
Comment 5 Chris Wilson 2012-04-22 11:23:05 UTC
Likely we need to pass to the HDA developers.
Comment 6 alanw 2012-04-22 11:45:53 UTC
(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.
Comment 7 Staffan Lindberg 2012-04-22 12:32:48 UTC
I can confirm these HD Audio passthrough issues with 3.3.2 kernel, Alsa 1.0.25 and an Intel DH67CF motherboard
Comment 8 Chris Wilson 2012-04-22 12:42:04 UTC
(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.
Comment 9 alanw 2012-04-22 13:01:45 UTC
(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.
Comment 10 Anssi Hannula 2012-04-22 17:01:38 UTC
(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.
Comment 11 Frederik 2012-07-24 18:35:18 UTC
(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.
Comment 12 Daniel Vetter 2012-07-24 18:38:08 UTC
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).
Comment 13 Anssi Hannula 2012-07-24 19:12:51 UTC
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.
Comment 14 Frederik 2012-07-24 21:24:46 UTC
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
Comment 15 Wang Xingchao 2012-07-27 10:02:17 UTC
(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.
Comment 16 Wang Xingchao 2012-09-05 06:48:37 UTC
Created attachment 66654 [details] [review]
cover letter
Comment 17 Wang Xingchao 2012-09-05 06:49:37 UTC
Created attachment 66655 [details] [review]
fix channel allocation order

fix channel allocation order
Comment 18 Wang Xingchao 2012-09-05 06:50:39 UTC
Created attachment 66656 [details] [review]
patch 2
Comment 19 Wang Xingchao 2012-09-05 06:50:56 UTC
Created attachment 66657 [details] [review]
patch 3
Comment 20 Wang Xingchao 2012-09-05 06:51:58 UTC
Created attachment 66658 [details] [review]
patch 1
Comment 21 alanw 2012-09-05 20:01:04 UTC
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.
Comment 22 Oyvind Kvalsvoll 2012-09-06 03:47:12 UTC
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.
Comment 23 Chris Wilson 2012-10-17 22:30:21 UTC
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.