Bug 98797 - [BXT/KBL] - HDMI - HD audio passthrough dont work
Summary: [BXT/KBL] - HDMI - HD audio passthrough dont work
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
: 101835 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-11-20 15:30 UTC by Piotr Kasp.
Modified: 2017-09-28 20:36 UTC (History)
22 users (show)

See Also:
i915 platform: BXT, KBL, SKL
i915 features: display/audio, display/DP, display/LSPCON


Attachments
Hardware log (48.91 KB, text/x-matlab)
2016-11-20 15:30 UTC, Piotr Kasp.
no flags Details
dmesg + lsmod (61.53 KB, text/x-matlab)
2016-11-20 15:31 UTC, Piotr Kasp.
no flags Details
dmesg with drm.debug=14 (56.36 KB, text/x-matlab)
2016-11-22 12:57 UTC, Piotr Kasp.
no flags Details
dmesg with drm.debug=14 (fix, correct one) kernel 4.6rc6 (70.67 KB, text/x-matlab)
2016-11-22 13:01 UTC, Piotr Kasp.
no flags Details
dmesg + patch 120871 (70.91 KB, text/x-matlab)
2016-11-23 03:18 UTC, Piotr Kasp.
no flags Details
Datasheet of MCDP28x0p (deleted)
2017-01-11 16:45 UTC, Piotr Kasp.
no flags Details
dmesg output of drm-tip (154.86 KB, text/plain)
2017-02-15 20:35 UTC, Peter Frühberger
no flags Details
attachment-24995-0.html (2.32 KB, text/html)
2017-02-18 11:03 UTC, vinod.koul
no flags Details
attachment-10654-0.html (2.33 KB, text/html)
2017-04-10 18:00 UTC, vinod.koul
no flags Details
attachment-10709-0.html (2.88 KB, text/html)
2017-04-10 18:01 UTC, shashank.sharma@intel.com
no flags Details
dmesg - drm-tip: 2017y-04m-13d-15h-12m-23s UTC integration manifest (60.23 KB, text/plain)
2017-04-13 17:04 UTC, Piotr Kasp.
no flags Details
attachment-2492-0.html (3.30 KB, text/html)
2017-08-11 16:32 UTC, Ariel
no flags Details
attachment-8241-0.html (2.98 KB, text/html)
2017-08-11 21:25 UTC, Ramesh Babu
no flags Details
attachment-21387-0.html (2.98 KB, text/html)
2017-08-23 02:32 UTC, Ramesh Babu
no flags Details
hbr compressed audio fix by programming ICT bits (2.63 KB, patch)
2017-09-19 15:24 UTC, Subhransu
no flags Details | Splinter Review
hbr compressed audio fix by programming ICT bits (2.63 KB, patch)
2017-09-19 15:25 UTC, Subhransu
no flags Details | Splinter Review
attachment-3824-0.html (3.63 KB, text/html)
2017-09-23 00:52 UTC, Ramesh Babu
no flags Details
attachment-17386-0.html (2.33 KB, text/html)
2017-09-28 20:36 UTC, vinod.koul
no flags Details
attachment-17443-0.html (4.29 KB, text/html)
2017-09-28 20:36 UTC, Ramesh Babu
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Piotr Kasp. 2016-11-20 15:30:43 UTC
Created attachment 128087 [details]
Hardware log

Hi
Im owner of Asrock maiboard J3455-itx which i based on Apollo Lake CPU (broxton GPU)

i have problem get working HD audio passthrough.
I know on mainboard is chip which convert DP 1.2 to HDMI 2.0
this one http://www.megachips.com/products/displayport/MCDP28x0

Normal AC3 sound and DTS working, any higher format not.
Im using latest kernel fork drm-intel-nighlty (	drm-intel-nightly: 2016y-11m-18d-22h-35m-31s UTC ) with merged latest asock kernel-next chnages.

Im also in my test build used, latest x86-video-intel driver, latest mesa, xorg, libvaapi etc. 


System is LibreELEC (linux with Kodi)
i have connected maniboard to AVR Harman BDS570 which support TureHD and DTS-MA
what Kodi me exposed in log file

13:31:11.773 T:140598541641792  NOTICE:         m_deviceName      : hdmi:CARD=PCH,DEV=0
13:31:11.773 T:140598541641792  NOTICE:         m_displayName     : HDA Intel PCH
13:31:11.773 T:140598541641792  NOTICE:         m_displayNameExtra: HKK SAMSUNG on DisplayPort #0
13:31:11.773 T:140598541641792  NOTICE:         m_deviceType      : AE_DEVTYPE_HDMI
13:31:11.773 T:140598541641792  NOTICE:         m_channels        : FL,FR,LFE,FC,BL,BR
13:31:11.773 T:140598541641792  NOTICE:         m_sampleRates     : 32000,44100,48000,88200,96000,176400,192000
13:31:11.773 T:140598541641792  NOTICE:         m_dataFormats     : AE_FMT_RAW,AE_FMT_S32NE,AE_FMT_S16NE,AE_FMT_S16LE,AE_FMT_RAW
13:31:11.773 T:140598541641792  NOTICE:         m_streamTypes     : STREAM_TYPE_AC3,STREAM_TYPE_DTSHD,STREAM_TYPE_DTSHD_CORE,STREAM_TYPE_DTS_1024,STREAM_TYPE_DTS_2048,STREAM_TYPE_DTS_512,STREAM_TYPE_EAC3,STREAM_TYPE_TRUEHD

but no HD sound.
Comment 1 Piotr Kasp. 2016-11-20 15:31:25 UTC
Created attachment 128088 [details]
dmesg + lsmod
Comment 2 Piotr Kasp. 2016-11-20 15:44:49 UTC
here more info logs/info from sound.

cat /proc/asound/cards
 0 [PCH            ]: HDA-Intel - HDA Intel PCH
                      HDA Intel PCH at 0x91310000 irq 127

cat /proc/asound/PCH/codec\#2
http://sprunge.us/XJei

cat /proc/asound/PCH/codec\#0
http://sprunge.us/SZGK

 cat /proc/asound/PCH/eld\#2.0
http://sprunge.us/fBMZ
Comment 3 Piotr Kasp. 2016-11-22 12:47:19 UTC
on latest kernel drm-intel drm-intel-nightly: 2016y-11m-21d-18h-22m-22s
commit	eeec5e7742b23082dd20523c8baa08fe495175e4

dmesg log:
http://sprunge.us/DPGj
Comment 4 Piotr Kasp. 2016-11-22 12:57:34 UTC
Created attachment 128144 [details]
dmesg with drm.debug=14
Comment 5 Piotr Kasp. 2016-11-22 13:01:13 UTC
Created attachment 128145 [details]
dmesg with drm.debug=14 (fix, correct one) kernel 4.6rc6
Comment 6 Imre Deak 2016-11-22 13:07:08 UTC
Adding Libin for audio.
Comment 7 Libin Yang 2016-11-23 02:59:37 UTC
We found a HDMI audio issue before. Could you please test this patch:
https://patchwork.freedesktop.org/patch/120871/

And We don't support HBR audio. So if you are using the HBR audio, HDMI audio will not work.
Comment 8 Piotr Kasp. 2016-11-23 03:18:47 UTC
Created attachment 128156 [details]
dmesg + patch 120871

Im used you patch for kernel - but nothing help in this case.
Still only AC3 and DTS works, nothing higher - just no audio signal on AVR ...
Comment 10 Piotr Kasp. 2016-11-23 03:45:37 UTC
people raported its for for braswell and other HBR
this resolve some issue for them

https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/linux/patches/4.8.9/linux-990.06-hda-Avoid-outputting-HDMI-audio-before-prepare-.patch

more here where works for people
http://forum.kodi.tv/showthread.php?tid=136555
Comment 11 Libin Yang 2016-11-23 06:11:37 UTC
(In reply to Piotr Kasp. from comment #9)
> what about that info ? 
> http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/
> ?id=433968da4d93a194b79da552f4ca707f979ef33b

Not sure the detail about the patch. I did the test on HBR audio (such as True HD) before, it doesn't work.
Comment 12 Piotr Kasp. 2016-11-23 09:54:58 UTC
HBR is supported in kernel from 2012
http://www.phoronix.com/scan.php?page=news_item&px=MTE4MDQ

For my CPU/GPU works winthout problem on windows.
For little older CPU works in Linux.

on used kernel 4.9rc6 system show codec: Intel Broxton HDMI
with HBR support
here log: http://sprunge.us/KSKf


So if that works for older and is support in kernel that is bug/issue :/

Im open to delivery anything you need, logs etc, or more debug.
Just let me know what do you need.
Comment 13 czombos 2016-11-27 18:12:27 UTC
A similar problem with the same motherboard (Asrock J3455-ITX)

AC3, DTS works
TrueHD, DTSHD not work

The two audio tracks when playing unsounded
aplay -D 'hdmi:CARD=PCH,DEV=0,AES0=2' -c8 -fs16_le -r192000 testi.truehd.anssi1.ff.60s.spdif
aplay -D 'hdmi:CARD=PCH,DEV=0,AES0=2' -c8 -fs16_le -r192000 testi.dtshd.anssi1.ma-71-24.spdif

kodi@HTPC:~$ aplay -D 'hdmi:CARD=PCH,DEV=0,AES0=2' -c8 -fs16_le -r192000 testi.truehd.anssi1.ff.60s.spdif
Playing raw data 'testi.truehd.anssi1.ff.60s.spdif' : Signed 16 bit Little Endian, Rate 192000 Hz, Channels 8

kodi@HTPC:~$ dpkg -l |grep mesa | pastebinit
http://paste.ubuntu.com/23544331/
kodi@HTPC:~$ DISPLAY=:0 vainfo | pastebinit
http://paste.ubuntu.com/23544333/
kodi@HTPC:~$ cat ~/.kodi/temp/kodi.log | pastebinit
http://paste.ubuntu.com/23544334/
kodi@HTPC:~$ dmesg | pastebinit
http://paste.ubuntu.com/23544335/
kodi@HTPC:~$ id | pastebinit
http://paste.ubuntu.com/23544336/
kodi@HTPC:~$ amixer | pastebinit
http://paste.ubuntu.com/23544337/

http://forum.kodi.tv/showthread.php?tid=297918&pid=2464723#pid2464723
Comment 14 Piotr Kasp. 2016-11-27 18:32:43 UTC
on other mainboard same problem and on miniPC Asus Vivo based on Skylake so problem is bigger
Comment 15 Piotr Kasp. 2016-11-27 18:32:58 UTC
on other mainboard same problem and on miniPC Asus Vivo based on Skylake so problem is bigger
Comment 16 Peter Frühberger 2016-12-06 19:50:36 UTC
Here is the technical documentation of MCDP28x0 chip used: https://media.digikey.com/pdf/Data%20Sheets/MegaChips%20PDFs/MCDP28x0_Datasheet.pdf

It states to support HBR Audio via 2 channels and 768 khz. While HD-Audio Standard does not explicitely talk about channels when talking about HD-Audio, it is common to transmit HD-Audio with 192 khz and 8 channels.

If this converter wants this explicitely transfered in 2 channel 768 khz (same bandwidth) perhaps this need to be mapped properly, e.g. setting its clock to 768 khz and transmitting the input signal 2 channel size wise?

Just an idea to bring this bug here to the next level.
Comment 17 Piotr Kasp. 2016-12-07 19:56:34 UTC
Some people raported working correct passthrough with DVI adapter.
All format working fine, including Dolby Atmos !!!!

here log with drm debug (with DVI adapter)
http://sprunge.us/dHSY

Here without 
http://sprunge.us/QcDj
Comment 18 Piotr Kasp. 2016-12-08 09:58:45 UTC
anyone looking in this ticket ? i dont know what more we can delivery ..
Comment 19 Libin Yang 2016-12-12 01:54:11 UTC
Not sure how DVI adapter can help on this issue.

Based on my knowledge before, the format such as trueHD doesn't work for HDMI/DP audio. It missed some registers setting.
Comment 20 Libin Yang 2016-12-12 01:57:26 UTC
add Vinod.

Hi Vinod,

Do you or your team has plan or already has done to support the formats such as TrueHD?

Thanks,
Libin
Comment 21 Piotr Kasp. 2016-12-12 02:12:15 UTC
I dont know either, but it works.
All hd audio format like TrueHD, DTS-MA, Dolby Atmos.
Over DVI port on mainboard with adapter to HDMI

So something is Broken with DP port and conversion to HDMI
Comment 22 Piotr Kasp. 2017-01-11 16:45:25 UTC
Created attachment 128891 [details]
Datasheet of MCDP28x0p
Comment 23 Jani Nikula 2017-01-12 08:40:53 UTC
Comment on attachment 128891 [details]
Datasheet of MCDP28x0p

Please do not attach documents that can't be freely distributed.
Comment 24 Martin Peres 2017-01-12 08:45:44 UTC
The content of attachment 128891 [details] has been deleted for the following reason:

proprietary information is contained!
Comment 25 nucblog.net 2017-01-15 15:56:09 UTC
The exactly same problem can be seen using an Intel Apollo Lake NUC (NUC6CAYH). The NUC only has 1 HDMI port, so there's no way to work around this issue.

If needed, can provide debug information (just let me know what you want to see).
Comment 26 Ariel 2017-01-25 19:00:00 UTC
Just to add that this issue also affects Asrock J4205 mobo, Fedora 25, Kernel 4.9.5
Comment 27 nucblog.net 2017-02-09 20:52:06 UTC
I'm running an Intel NUC7i3BNH (Kaby Lake i3 NUC with i3-7100U) and can confirm that the same issue can be seen with the Kaby Lake as well. Presumably the same DP-to-HDMI2 conversion chip is used in this NUC as in NUC6CAYH.
Comment 28 Jani Nikula 2017-02-15 12:18:49 UTC
Please try current drm-tip branch of https://cgit.freedesktop.org/drm-tip
Comment 29 Peter Frühberger 2017-02-15 20:35:18 UTC
Hi Jani,

sadly no change with this kernel. Find attached the dmesg output from the start.
Comment 30 Peter Frühberger 2017-02-15 20:35:55 UTC
Created attachment 129658 [details]
dmesg output of drm-tip
Comment 31 Peter Frühberger 2017-02-16 20:47:58 UTC
Is there anything I can provide to get the bug away from NEEDINFO? If yes, please tell us.
Comment 32 Dennis_digital-words.de 2017-02-18 11:03:19 UTC
Right now we're testing the Beebox-S 7100U and this one has the same problem.

I would much appreciate if someone could fix this bug. Without this bug the current Mini PC Series (NUC, Beebox etc.) would run perfect with LibreELEC.Right now we're testing the Beebox-S 7100U and this one has the same problem.

I would much appreciate if someone could fix this bug. Wihtout this bug the actual Mini PC Series (NUC, Beebox etc.) would run perfect with LibreELEC.
Comment 33 vinod.koul 2017-02-18 11:03:57 UTC
Created attachment 129729 [details]
attachment-24995-0.html

Thanks for your email

I am attending ELC-NA
Please expect delayed response.

Regards
--
~Vinod
Comment 34 Dennis_digital-words.de 2017-02-18 11:06:29 UTC
Please delete my last comment, saved it to early. :)

Right now we're testing the Beebox-S 7100U and this one has the same problem.

I would much appreciate if someone could fix this bug. Without this bug the current Mini PC Series (NUC, Beebox etc.) would run perfect with LibreELEC.

If we can support you in any way, please let me know.
Comment 35 Chris 2017-02-19 11:44:26 UTC
Had the same problem with miniDP1.2->HDMI2.0 adapter on several NUC models and NUC6i7KYK has the same issue. Is it firmware related?
Comment 36 Imre Deak 2017-02-20 12:26:47 UTC
(In reply to nucblog.net from comment #27)
> I'm running an Intel NUC7i3BNH (Kaby Lake i3 NUC with i3-7100U) and can
> confirm that the same issue can be seen with the Kaby Lake as well.
> Presumably the same DP-to-HDMI2 conversion chip is used in this NUC as in
> NUC6CAYH.
>
(In reply to Chris from comment #35)
> Had the same problem with miniDP1.2->HDMI2.0 adapter on several NUC models
> and NUC6i7KYK has the same issue. Is it firmware related?

Hi, this bug is for APL/BXT based platforms. Could you please open a new bug for the KBL issues you reported, using the latest drm-tip kernel and providing a dmesg log booting with drm.debug=14?
Comment 37 nucblog.net 2017-02-24 23:10:14 UTC
I did upgrade the firmware of the MCDP2800 LSPCon on my Apollo Lake NUC (NUC6CAYH) to 1.61, but the problem seems to persist.
Comment 38 Dennis_digital-words.de 2017-02-26 12:55:27 UTC
Apollo Lake NUC (NUC6CAYH) and Beebox shows the same behavior.

With the new Firmware (1.61) for the DP-HDMI converterchip, HD-Audio works fine with Kodi in Windows, but with LibreELEC still no sound available.
Comment 39 chrisk2305 2017-02-27 06:21:07 UTC
I can confirm HD Audio Passthrough not working on Asrock J4205-ITX with FW 1.61  running drm-tip @ revision: Commit:0be4ca1 namely: drm-tip: 2017y-02m-25d-19h-02m-26s UTC integration manifest
Comment 40 Dennis_digital-words.de 2017-03-09 18:27:09 UTC
Any news about this problem?

Do you need more specific information? Please just let me know.
Comment 41 Ricardo 2017-03-09 20:51:04 UTC
I think we got good information here
Comment 42 Michael Carroll 2017-03-14 16:06:41 UTC
FYI
Per this discussion: https://communities.intel.com/thread/110994, this seems to be working at 60Hz refresh and/or 4K resolution, but not down at 1080p24 with FW1.61. Last update from Intel says they've escalated to MegaChips for a solution.
Comment 43 chrisk2305 2017-03-22 14:11:32 UTC
I can confirm that HD sound does NOT work with libreelec, J4205-ITX and new FW 1.65 connected via HDMI 2.0 (DP) to HDMI 2.0 capable equipment.
Comment 44 chrisk2305 2017-04-10 18:00:26 UTC
neither with fw 1.66
Comment 45 vinod.koul 2017-04-10 18:00:56 UTC
Created attachment 130785 [details]
attachment-10654-0.html

Thanks for your email

I am on vacation till April 23rd
Please expect delayed response.

Regards
--
~Vinod
Comment 46 shashank.sharma@intel.com 2017-04-10 18:01:20 UTC
Created attachment 130786 [details]
attachment-10709-0.html

Hello,
I am on vacation between 06 Dec - 16 Dec  with limited Phone and no mail access.
Please expect delay in response.

If this is something urgent, please contact my manager : Indranil, Mukherjee

Regards
Shashank
Comment 47 Piotr Kasp. 2017-04-11 21:42:23 UTC
here log from testing THD, Atmos, DD+ on latest drm-nighlty kernel with MegaChip firmware v1.66 which is confirmed as fixed HD audio passthrough on Windows.

http://sprunge.us/EgBC
Comment 48 Jani Nikula 2017-04-12 06:46:58 UTC
(In reply to Piotr Kasp. from comment #47)
> here log from testing THD, Atmos, DD+ on latest drm-nighlty kernel with
> MegaChip firmware v1.66 which is confirmed as fixed HD audio passthrough on
> Windows.
> 
> http://sprunge.us/EgBC

Please attach logs in the bug, see "Add an attachment" near the top. The external sites tend to lose the content, and we're left with nothing.
Comment 49 Piotr Kasp. 2017-04-13 17:04:12 UTC
Created attachment 130832 [details]
dmesg - drm-tip: 2017y-04m-13d-15h-12m-23s UTC integration manifest

here dmesg drm-debug=14 from kernel 4.11rc6 branch drm-tip: 2017y-04m-13d-15h-12m-23s UTC integration manifest

tested on NUC with MegaChip fw 1.66 (fixed HD audio for windows)
during test was played 3 test files with HD audio (treuHD, DTS-MA, Atmos)
Comment 50 Peter Frühberger 2017-06-05 17:23:46 UTC
The issue persists with same symptomes running drm-tip from yesterday. Anything else we should try?
Comment 51 Kuta 2017-06-25 08:42:59 UTC
intel NUC6CAYH

Updated BIOS to latest AYAPLCEL.86A.0038 (http://intel.ly/2t4MscK)
Updated Megachip HDMI Firmware to 1.66 via Windows only software (http://intel.ly/2tI9kwH)

Windows 10 : HDMI audio output as expected at all resolutions.
Xubuntu 17.04 (Kernel 4.10x : No HDMI audio at any resolution.
Librelec 8.02 : No HDMI audio at any resolution.

...
Comment 52 Peter Frühberger 2017-06-25 08:49:19 UTC
Your bug is completely different to what is filed here. Normal audio playback, especially 2.0 channel output works for everyone (TM).

This bug here is about HD audio passthrough only. If you meant that, then please be more precise next time.
Comment 53 Kuta 2017-06-25 08:50:22 UTC
MCDP28x0 DisplayPort1.2a-to-HDMI 2.0 Converter

http://www.megachips.com/products/displayport/MCDP28x0

...
Comment 54 Kuta 2017-06-25 08:51:17 UTC
(In reply to Peter Frühberger from comment #52)
> Your bug is completely different to what is filed here. Normal audio
> playback, especially 2.0 channel output works for everyone (TM).
> 
> This bug here is about HD audio passthrough only. If you meant that, then
> please be more precise next time.

Not this everybody..
Comment 55 Jani Nikula 2017-07-04 07:58:18 UTC
(In reply to Kuta from comment #54)
> (In reply to Peter Frühberger from comment #52)
> > Your bug is completely different to what is filed here. Normal audio
> > playback, especially 2.0 channel output works for everyone (TM).
> > 
> > This bug here is about HD audio passthrough only. If you meant that, then
> > please be more precise next time.
> 
> Not this everybody..

Please file a separate bug for your issue. Conflating bugs just makes debugging harder. Thanks.
Comment 57 shashank.sharma@intel.com 2017-08-09 03:36:31 UTC
With the local validation, we are able to hear HDMI audio on a SKL NUC / SKL RVP using Ubuntu 17.04. This seems to  be  a configuration problem. Linux audio team is looking into it.

- Shashank
Comment 58 Peter Frühberger 2017-08-09 04:37:28 UTC
To clarify once more:

We all don't have a problem with PCM audio. That works fine everywhere. We are talking about HD audio passthrough some call it bitstreaming. That means passing through a raw bitstream for DTS-HD / DTS-X / TrueHD / Dolby Atmos and so on.

You can verify this by testing e.g.:

aplay -D hdmi:CARD=PCH,DEV=0,AES0=0x06 -c8 -fs16_le -r192000 dts.spdif

Testfiles you can find here: http://www.avenard.org/files/media/mediatest/audiotest/HDAUDIO/Passthrough/

Please let me emphasize once again: 
This bug is not about PCM output - it is a bout raw passthrough - see the AES0=0x06 in the above command in above command.
Comment 59 Peter Frühberger 2017-08-09 04:40:09 UTC
And something else I overlooked: SKL is perfect. This bug is about BXT (Broxton, someone wrote falseley Braswell somewhere) and its DisplayPort to HDMI 2.0 bridge (MCDP28x0)
Comment 60 shashank.sharma@intel.com 2017-08-09 06:18:18 UTC
- If I was not clear, while I tested HDMI audio, that was using a HDMI cable which is coming out of MCA LSPCON based HDMI port, and the audio was from HDMI monitor speakers / Headphones. This is HDMI audio, and I don't see a reason why would we relate anything else (like PCM audio) with this, and this is the only thing related to LSPCON, and a Graphics team needs to think about. I am not talking about on-board audio. 
- Both SKL and BXT use MCA LSPCON MC2x00 series, and if this works for SKL, I don't see a reason why not for BXT (until there is a HW failure).
- As BXT program was cancelled, we don't have any more BXT based boards available to test on, all our LSPCON/GEN9 testing is being done on APL/SKL/KBL NUCs and all are working well.
Comment 61 chrisk2305 2017-08-09 06:25:25 UTC
the problem exists for every platform with the LSPCON MC2x00 series DP to HDMI Converter.

HD Audio passthrough is relevant for i.e HTPC setups where the pc is connected to a receiver that is supposed to handle the bitstream coming from the hdmi port.
Comment 62 dCrypt 2017-08-09 07:30:59 UTC
(In reply to shashank.sharma@intel.com from comment #60)
> - As BXT program was cancelled, we don't have any more BXT based boards
> available to test on, all our LSPCON/GEN9 testing is being done on
> APL/SKL/KBL NUCs and all are working well.

It's a bit confusing that you talk about not having a BXT board but testing in APL (Apollo Lake) when we are all referring to Apollo Lake boards and NUCs (J3455 based). BXT is just the name of the graphics core architecture of Apollo Lake GPU (AFAIK), as shown in the bug "i915 platform" list.
Comment 63 Igor Mammedov 2017-08-09 12:29:38 UTC
(In reply to Peter Frühberger from comment #59)
> And something else I overlooked: SKL is perfect.
It doesn't work in all cases,
I have P10S-M WS (C236 chipset) and KBL CPU and before that SKL CPU on the same board,
in both cases HBR audio (dts-hd passthrough) in linux kernel is broken.

What is common with Apollo Lake platform here is the lack of native HDMI output and HDMI2.0 port is wired up to DisplayPort via some convertor chip. The HBR-audio also doesn't work in case when DisplayPort output is used with external DP->HDMI cable
(it's not HW issue as both ways work as expected with Win10).
Comment 64 Igor Mammedov 2017-08-09 12:42:57 UTC
(In reply to shashank.sharma@intel.com from comment #60)
> - If I was not clear, while I tested HDMI audio, that was using a HDMI cable
> which is coming out of MCA LSPCON based HDMI port, and the audio was from
> HDMI monitor speakers / Headphones. This is HDMI audio, and I don't see a
> reason why would we relate anything else (like PCM audio) with this
PCM audio here means uncompressed audio data played over HDMI,
but the problem is with compressed (DTSHD - aka DTS Master Audio and/ TRUEHD) data passthrough via the same HDMI output.

Does command suggested in comment 58 works for you?

Could you describe exact steps you are using to reproduce bug?
Comment 65 Jani Nikula 2017-08-10 14:32:53 UTC
*** Bug 101056 has been marked as a duplicate of this bug. ***
Comment 66 Jani Nikula 2017-08-10 14:35:26 UTC
*** Bug 101835 has been marked as a duplicate of this bug. ***
Comment 67 Jani Nikula 2017-08-10 14:41:17 UTC
(In reply to chrisk2305 from comment #61)
> the problem exists for every platform with the LSPCON MC2x00 series DP to
> HDMI Converter.
> 
> HD Audio passthrough is relevant for i.e HTPC setups where the pc is
> connected to a receiver that is supposed to handle the bitstream coming from
> the hdmi port.

Per https://bugs.freedesktop.org/show_bug.cgi?id=101835#c11 also Parade LSPCON fails passthrough, so more likely a generic LSPCON problem.
Comment 68 Jani Nikula 2017-08-10 14:42:13 UTC
(In reply to Jani Nikula from comment #67)
> Per https://bugs.freedesktop.org/show_bug.cgi?id=101835#c11 also Parade
> LSPCON fails passthrough, so more likely a generic LSPCON problem.

Err, LSPCON related problem in i915.
Comment 69 Igor Mammedov 2017-08-10 16:28:40 UTC
(In reply to Jani Nikula from comment #68)
> (In reply to Jani Nikula from comment #67)
> > Per https://bugs.freedesktop.org/show_bug.cgi?id=101835#c11 also Parade
> > LSPCON fails passthrough, so more likely a generic LSPCON problem.
> 
> Err, LSPCON related problem in i915.

Are you sure it's LSPCON related issue?
It's true that there were LSPCON related problems in NUCs and that were fixed by it's firmware update.

Moreover I have 'ASUS P10S-M WS' with similar setup where internal DP port is connected through unknown convertor chip to HDMI output connector. Considering that this chip
works fine (DTSHD passthrough) under Windows 10 without any firmware updates I would assume that it's not LSPCON chip, but HD-audio is broken in linux anyway. Also the board has additional DP output[1], which has the same HD-audio passthrough issues under linux but works fine under Windows.

Considering that issue affects other HW,
I'd not limit BZ to LSPCON only as the problem is wider,
so I'd keep BZ title as it's been before.
it looks like DP is a common denominator on all boards that exhibit the problem regardless of internal/external convertor,
so it looks like the place to start looking for issue.


(1) - to connect DP output to HDMI reciever I use:
        Club3D DisplayPort 1.2 Cable to HDMI 2.0 Active Adapter (P/N: CAC-1073)
Comment 70 Ramesh Babu 2017-08-10 16:50:45 UTC
>> It's true that there were LSPCON related problems in NUCs and that were fixed by it's firmware update.

Can you please point us to this firmware update?
In Linux, As far as I Know, LSPCON driver downloads the FW to LSPCON chip. So need to make sure Linux also has latest FW.
Comment 71 dCrypt 2017-08-10 17:26:39 UTC
(In reply to Ramesh Babu from comment #70)
> >> It's true that there were LSPCON related problems in NUCs and that were fixed by it's firmware update.
> 
> Can you please point us to this firmware update?
> In Linux, As far as I Know, LSPCON driver downloads the FW to LSPCON chip.
> So need to make sure Linux also has latest FW.

https://downloadcenter.intel.com/download/26609/NUCs-HDMI-2-0-Firmware-Update-Tool-for-Intel-NUC-Kit-NUC6CAY-and-NUC7i3BN?product=95062
Comment 72 Jani Nikula 2017-08-10 18:03:01 UTC
(In reply to Ramesh Babu from comment #70)
> In Linux, As far as I Know, LSPCON driver downloads the FW to LSPCON chip.
> So need to make sure Linux also has latest FW.

There is no LSPCON driver in Linux, it's just part of drm/i915. And it does *not* update the LSPCON firmware.
Comment 73 Jani Nikula 2017-08-10 18:11:11 UTC
(In reply to Igor Mammedov from comment #69)
> Are you sure it's LSPCON related issue?

That's my educated guess.

> It's true that there were LSPCON related problems in NUCs and that were
> fixed by it's firmware update.

An LSPCON firmware update fixing something isn't proof that there aren't other LSPCON related issues in the drm drivers.

> Moreover I have 'ASUS P10S-M WS' with similar setup where internal DP port
> is connected through unknown convertor chip to HDMI output connector.
> Considering that this chip
> works fine (DTSHD passthrough) under Windows 10 without any firmware updates
> I would assume that it's not LSPCON chip, but HD-audio is broken in linux
> anyway. Also the board has additional DP output[1], which has the same
> HD-audio passthrough issues under linux but works fine under Windows.
> 
> Considering that issue affects other HW,
> I'd not limit BZ to LSPCON only as the problem is wider,
> so I'd keep BZ title as it's been before.
> it looks like DP is a common denominator on all boards that exhibit the
> problem regardless of internal/external convertor,
> so it looks like the place to start looking for issue.
> 
> 
> (1) - to connect DP output to HDMI reciever I use:
>         Club3D DisplayPort 1.2 Cable to HDMI 2.0 Active Adapter (P/N:
> CAC-1073)

AFAICT all of the scenarios you describe consist of an active protocol converter. The same chips that are used for the internal LSPCON are used within adapter cables.

Is anyone here experiencing issues with native DP or native HDMI, with no active protocol converters in between?
Comment 74 Jani Nikula 2017-08-10 18:15:03 UTC
I haven't had the time to dig into this, I'm hoping someone else will, but I wouldn't be surprised if the problem has to do with some confusion arising from EDID information being fetched from an HDMI display (or A/V receiver) but the driver seeing a DP connector. There might be something we're not taking into account there.
Comment 75 dCrypt 2017-08-10 20:13:15 UTC
(In reply to Jani Nikula from comment #73)
> Is anyone here experiencing issues with native DP or native HDMI, with no
> active protocol converters in between?

Native DP->AVR DP (for HD audio passthrough, decoding in the AVR), I'm not really sure but I doubt it. No AVR with DP input known so far.
Comment 76 Achilles 2017-08-11 04:50:15 UTC
(In reply to Jani Nikula from comment #74)
> I haven't had the time to dig into this, I'm hoping someone else will, but I
> wouldn't be surprised if the problem has to do with some confusion arising
> from EDID information being fetched from an HDMI display (or A/V receiver)
> but the driver seeing a DP connector. There might be something we're not
> taking into account there.

You are right on the money here. This is what I have concluded since the Skull Canyon NUC. Please find time to dig into this. You are the only Intel Engineer thus far from my opinion that has come close to pinpointing the root case here.
Comment 77 shashank.sharma@intel.com 2017-08-11 04:51:31 UTC
Being the graphics team, we just test audio by:
1. Connect HDMI monitor
2. Play a video (using the std Ubuntu video player)from the std video list, check on HDMI monitor's speakers / Audio
3. Play an audio using any of the audio players. 

This confirms us that HDMI Audio over LSPCON is working. 

Any detailed audio / codec / sound card and bit rate related testing is beyond graphics scope and should be done by the Audio team (which they are doing right now, I am in loop with them)

Also, we are using LSPCON FW SW version 1.66 HW version 2.2

Shashank
Comment 78 Peter Frühberger 2017-08-11 04:55:04 UTC
@Shashank: Yeah please sync with Jani / Audio-Team offline on that matter as what you are currently testing has nothing to do with this bugreport here.
Comment 79 Jani Nikula 2017-08-11 05:45:48 UTC
*** Bug 101835 has been marked as a duplicate of this bug. ***
Comment 80 Achilles 2017-08-11 06:44:24 UTC
(In reply to Peter Frühberger from comment #59)
> And something else I overlooked: SKL is perfect. This bug is about BXT
> (Broxton, someone wrote falseley Braswell somewhere) and its DisplayPort to
> HDMI 2.0 bridge (MCDP28x0)

This is partly accurate. The Skull Canyon has a Skylake but also uses a Parade LSPCon so the issue exists on it as well. Most Skylake boards reverted back to using a native HDMI 1.4b port.
Comment 81 Achilles 2017-08-11 07:08:55 UTC
(In reply to Peter Frühberger from comment #78)
> @Shashank: Yeah please sync with Jani / Audio-Team offline on that matter as
> what you are currently testing has nothing to do with this bugreport here.
@shashank
You need to test HD audio bitstreaming/passthrough and not PCM audio that has been decoded by a player.
https://01.org/linuxgraphics/gfx-docs/drm/ch04s02.html#id-1.4.3.4.10
Comment 82 Jani Nikula 2017-08-11 07:42:55 UTC
(In reply to Achilles from comment #81)
> (In reply to Peter Frühberger from comment #78)
> > @Shashank: Yeah please sync with Jani / Audio-Team offline on that matter as
> > what you are currently testing has nothing to do with this bugreport here.
> @shashank
> You need to test HD audio bitstreaming/passthrough and not PCM audio that
> has been decoded by a player.

Yeah, we have a gap here. Libin?

> https://01.org/linuxgraphics/gfx-docs/drm/ch04s02.html#id-1.4.3.4.10

I hope we don't have any links pointing to the old formatting, the up to date link is:

https://01.org/linuxgraphics/gfx-docs/drm/gpu/i915.html#high-definition-audio
Comment 83 Libin Yang 2017-08-11 08:31:35 UTC
(In reply to Jani Nikula from comment #82)
> (In reply to Achilles from comment #81)
> > (In reply to Peter Frühberger from comment #78)
> > > @Shashank: Yeah please sync with Jani / Audio-Team offline on that matter as
> > > what you are currently testing has nothing to do with this bugreport here.
> > @shashank
> > You need to test HD audio bitstreaming/passthrough and not PCM audio that
> > has been decoded by a player.
> 
> Yeah, we have a gap here. Libin?

Do you mean the test cases? If yes, I think our QA can share the test cases internally. I'm not sure we can share the cases outsides.

For the HBR audio test, I can share some knowledge as I know.

There is 2 modes to play HBR audio, one is sw decode, the other is hw decode.
My understanding is this thread is talking about hw decode.

mplayer supports 2 modes with different parameters. If using hw decode, we need a AV receiver which supports hw decode (Some AV receivers need manually setting to use hw decode, others don't). 

So use hw decode in mplay and right setting in AV receiver can do the test for HBR audio.

> 
> > https://01.org/linuxgraphics/gfx-docs/drm/ch04s02.html#id-1.4.3.4.10
> 
> I hope we don't have any links pointing to the old formatting, the up to
> date link is:
> 
> https://01.org/linuxgraphics/gfx-docs/drm/gpu/i915.html#high-definition-audio
Comment 84 Achilles 2017-08-11 08:59:17 UTC
(In reply to Libin Yang from comment #83)
> (In reply to Jani Nikula from comment #82)
> > (In reply to Achilles from comment #81)
> > > (In reply to Peter Frühberger from comment #78)
> > > > @Shashank: Yeah please sync with Jani / Audio-Team offline on that matter as
> > > > what you are currently testing has nothing to do with this bugreport here.
> > > @shashank
> > > You need to test HD audio bitstreaming/passthrough and not PCM audio that
> > > has been decoded by a player.
> > 
> > Yeah, we have a gap here. Libin?
> 
> Do you mean the test cases? If yes, I think our QA can share the test cases
> internally. I'm not sure we can share the cases outsides.
> 
> For the HBR audio test, I can share some knowledge as I know.
> 
> There is 2 modes to play HBR audio, one is sw decode, the other is hw decode.
> My understanding is this thread is talking about hw decode.
Correct. The bug is with external HW decoding of HD Audio bitstreamed (not decoded) via DP->LSPCon->HDMI2.0 port to an AVR.

> 
> mplayer supports 2 modes with different parameters. If using hw decode, we
> need a AV receiver which supports hw decode (Some AV receivers need manually
> setting to use hw decode, others don't). 
> 
> So use hw decode in mplay and right setting in AV receiver can do the test
> for HBR audio.
You can test this with LibreELEC/KODI as well. I have tested this with the following Intel NUCs. All were connected to a Denon AVR-4311ci that handles the HD audio decoding.

NUCD54250WYK (Haswell): HD Audio bitstream works due to native HDMI1.4
NUC5PPYH (Braswell): HD Audio bitstream works due to native HDMI1.4
NUC5i7RYH (Broadwell): HD Audio bitstream works due to native HDMI1.4
NUC6i3SYK (Skylake): HD Audio bitstream works due to native HDMI1.4
NUC6i5SYK (Skylake): HD Audio bitstream works due to native HDMI1.4
NUC6i7KYK (Skylake): HD Audio bitstream doesn't work due to Parade LSPCon
NUC7i3BNK (Kaby Lake): HD Audio bitstream doesn't work due to MC2x00 LSPCon
NUC7i7BNH (Kaby Lake): HD Audio bitstream doesn't work due to MC2x00 LSPCon
Comment 85 Jani Nikula 2017-08-11 10:41:59 UTC
*** Bug 101835 has been marked as a duplicate of this bug. ***
Comment 86 Jani Nikula 2017-08-11 10:54:00 UTC
(In reply to Libin Yang from comment #83)
> Do you mean the test cases? If yes, I think our QA can share the test cases
> internally. I'm not sure we can share the cases outsides.

I mean, are you running any of the HBR audio tests with external HW decoding over LSPCON and HDMI 2.0? For certain we aren't.
Comment 87 samuelchueh 2017-08-11 11:05:13 UTC
Hi, 
 What status of the "LSPCON audio passthrough issues with i915" bug? 
We have the same issue on Bug 101835 
"[APL] HDMI 2.0 port cannot pass through Dolby TrueHD and DTS-HD under Linux". 

Thanks for your help!!!
Comment 88 Johnny Chen 2017-08-11 13:15:49 UTC
(In reply to Jani Nikula from comment #86)
> (In reply to Libin Yang from comment #83)
> > Do you mean the test cases? If yes, I think our QA can share the test cases
> > internally. I'm not sure we can share the cases outsides.
> 
> I mean, are you running any of the HBR audio tests with external HW decoding
> over LSPCON and HDMI 2.0? For certain we aren't.

Hi Jani,

Please help resolve it. This is very important. Many user wanna this function. 
Thanks for your help.
Comment 89 Jani Nikula 2017-08-11 13:29:04 UTC
Does passthrough work in Windows in PCON mode (HDMI 2.0), or only in LS mode (HDMI 1.4)? i915 always uses PCON mode.

I have no idea how to check this in Windows.
Comment 90 chrisk2305 2017-08-11 14:06:24 UTC
just try in Kodi. And yes it works in Windows.
Comment 91 Jani Nikula 2017-08-11 14:18:45 UTC
(In reply to chrisk2305 from comment #90)
> just try in Kodi. And yes it works in Windows.

Can you differentiate between PCON and LS modes of the LSPCON in Windows, and say with certainty that passthrough works in PCON mode in Windows?
Comment 92 chrisk2305 2017-08-11 14:25:18 UTC
(In reply to Jani Nikula from comment #91)
> (In reply to chrisk2305 from comment #90)
> > just try in Kodi. And yes it works in Windows.
> 
> Can you differentiate between PCON and LS modes of the LSPCON in Windows,
> and say with certainty that passthrough works in PCON mode in Windows?

It is proven in this thread: https://forum.kodi.tv/showthread.php?tid=270298&page=95

All Windows Users can use HD Audio passthrough via the HDMI 2.0 (LSPCON) with FW 1.66.
Comment 93 Jani Nikula 2017-08-11 14:43:00 UTC
(In reply to chrisk2305 from comment #92)
> It is proven in this thread:
> https://forum.kodi.tv/showthread.php?tid=270298&page=95
> 
> All Windows Users can use HD Audio passthrough via the HDMI 2.0 (LSPCON)
> with FW 1.66.

I'll take your word for it, rather than go through 95 pages of forums... ugh.

---

Random debug note: We don't consider audio bandwidth requirements for link training, only video mode. If the video mode just barely fits in the link, I think it'll impact audio.

Quick hack to try:

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 76c8a0bd17f9..983e78b4dc18 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1713,6 +1713,9 @@ intel_dp_compute_config(struct intel_encoder *encoder,
 		min_clock = max_clock;
 	}
 
+	min_lane_count = max_lane_count;
+	min_clock = max_clock;
+
 	for (; bpp >= 6*3; bpp -= 2*3) {
 		mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
 						   bpp);
Comment 94 Jani Nikula 2017-08-11 14:44:35 UTC
And for Friday lols, a complete shot in the dark:

diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c
index d805b6e6fe71..49e3847fcb01 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -608,8 +608,13 @@ void intel_audio_codec_enable(struct intel_encoder *intel_encoder,
 
        /* ELD Conn_Type */
        connector->eld[5] &= ~(3 << 2);
-       if (intel_crtc_has_dp_encoder(crtc_state))
-               connector->eld[5] |= (1 << 2);
+       if (intel_crtc_has_dp_encoder(crtc_state)) {
+               struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+               struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
+
+               if (!lspcon->active)
+                       connector->eld[5] |= (1 << 2);
+       }
 
        connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
Comment 95 Achilles 2017-08-11 15:32:51 UTC
(In reply to Jani Nikula from comment #89)
> Does passthrough work in Windows in PCON mode (HDMI 2.0), or only in LS mode
> (HDMI 1.4)? i915 always uses PCON mode.
> 
> I have no idea how to check this in Windows.

Passthrough works in Windows with both HDMI1.4 and 2.0 AVRs.
Comment 96 dCrypt 2017-08-11 15:49:37 UTC
(In reply to Jani Nikula from comment #89)
> Does passthrough work in Windows in PCON mode (HDMI 2.0), or only in LS mode
> (HDMI 1.4)? i915 always uses PCON mode.

Could it be just that, that LS mode is supported in Windows and not in Linux? I mean, I have HDMI 1.4 decoder and TV and my NUC6CAYH also fails in Linux, while it works in Windows. But I can't test in HDMI 2.0 equipment as I don't have access to any. I can't speak for the rest posting, but maybe it will be useful if someone can confirm that a native HDMI 2.0 AVR was tested in Linux. Not likely, but maybe we all share a common DP1.2->LSPCON->HDMI2.0->AVR HDMI 1.4 setup working in LS mode in Linux, thus failing.

(In reply to Jani Nikula from comment #91)
> (In reply to chrisk2305 from comment #90)
> > just try in Kodi. And yes it works in Windows.
> 
> Can you differentiate between PCON and LS modes of the LSPCON in Windows,
> and say with certainty that passthrough works in PCON mode in Windows?

And, more important, also say with tertainty that passthrough also fails in PCON mode in Linux (native HDMI 2.0 AVR) ... I haven't seen any confirmation of it within the thread.
Comment 97 Ariel 2017-08-11 16:32:25 UTC
Created attachment 133443 [details]
attachment-2492-0.html

I have tested with a native HDMI 2.0 AVR (denon x2300W) and TV and can
confirm that passthru FAILS in Linux, same as 1.4b. No difference.

To further clear doubts, during that test I confirmed that the HDMI
connection was working in 2.0 mode (18Gbps IIRC), playing back 4K 60fps
 content, reported by both the AVR and Kodi.


On Aug 11, 2017 11:49 AM, <bugzilla-daemon@freedesktop.org> wrote:

> *Comment # 96 <https://bugs.freedesktop.org/show_bug.cgi?id=98797#c96> on
> bug 98797 <https://bugs.freedesktop.org/show_bug.cgi?id=98797> from dCrypt
> <dcrypt@telefonica.net> *
>
> (In reply to Jani Nikula from comment #89 <https://bugs.freedesktop.org/show_bug.cgi?id=98797#c89>)> Does passthrough work in Windows in PCON mode (HDMI 2.0), or only in LS mode
> > (HDMI 1.4)? i915 always uses PCON mode.
>
> Could it be just that, that LS mode is supported in Windows and not in Linux? I
> mean, I have HDMI 1.4 decoder and TV and my NUC6CAYH also fails in Linux, while
> it works in Windows. But I can't test in HDMI 2.0 equipment as I don't have
> access to any. I can't speak for the rest posting, but maybe it will be useful
> if someone can confirm that a native HDMI 2.0 AVR was tested in Linux. Not
> likely, but maybe we all share a common DP1.2->LSPCON->HDMI2.0->AVR HDMI 1.4
> setup working in LS mode in Linux, thus failing.
>
> (In reply to Jani Nikula from comment #91 <https://bugs.freedesktop.org/show_bug.cgi?id=98797#c91>)> (In reply to chrisk2305 from comment #90 <https://bugs.freedesktop.org/show_bug.cgi?id=98797#c90>)
> > > just try in Kodi. And yes it works in Windows.
> >
> > Can you differentiate between PCON and LS modes of the LSPCON in Windows,
> > and say with certainty that passthrough works in PCON mode in Windows?
>
> And, more important, also say with tertainty that passthrough also fails in
> PCON mode in Linux (native HDMI 2.0 AVR) ... I haven't seen any confirmation of
> it within the thread.
>
> ------------------------------
> You are receiving this mail because:
>
>    - You are on the CC list for the bug.
>
>
Comment 98 Igor Mammedov 2017-08-11 21:25:40 UTC
(In reply to Jani Nikula from comment #94)
> And for Friday lols, a complete shot in the dark:
> 
> diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> index d805b6e6fe71..49e3847fcb01 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -608,8 +608,13 @@ void intel_audio_codec_enable(struct intel_encoder
> *intel_encoder,
>  
>         /* ELD Conn_Type */
>         connector->eld[5] &= ~(3 << 2);
> -       if (intel_crtc_has_dp_encoder(crtc_state))
> -               connector->eld[5] |= (1 << 2);
> +       if (intel_crtc_has_dp_encoder(crtc_state)) {
> +               struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> +               struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
> +
> +               if (!lspcon->active)
> +                       connector->eld[5] |= (1 << 2);
> +       }
>  
>         connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
it doesn't help (applied both comment 93 and this patch)

one observation:
  lspcon->active = 1 when using onboard HDMI2.0
  lspcon->active = 0 when using DP->HDMI2.0 cable

in both cases cables were connected to HDMI1.4b input on AVR.
Comment 99 Ramesh Babu 2017-08-11 21:25:52 UTC
Created attachment 133448 [details]
attachment-8241-0.html

Hello,

I'm OOO on ww33.1 and Ww33.2 is India Site holiday.
Expect delay in response to your emails.

For urgent issues, reachable on phone.

Thanks
Ramesh
Comment 100 Jani Nikula 2017-08-11 21:52:38 UTC
I was trying to say that i915 *always* uses PCON mode, and never LS mode, regardless of the sink or video mode. But apparently that is not a factor here.
Comment 101 Achilles 2017-08-11 22:04:24 UTC
(In reply to Jani Nikula from comment #93)
> (In reply to chrisk2305 from comment #92)
> > It is proven in this thread:
> > https://forum.kodi.tv/showthread.php?tid=270298&page=95
> > 
> > All Windows Users can use HD Audio passthrough via the HDMI 2.0 (LSPCON)
> > with FW 1.66.
> 
> I'll take your word for it, rather than go through 95 pages of forums... ugh.
> 
> ---
> 
> Random debug note: We don't consider audio bandwidth requirements for link
> training, only video mode. If the video mode just barely fits in the link, I
> think it'll impact audio.

Jani,

If I may add, Dolby Digital and DTS passthrough works and Stereo PCM works. These are all limited to 1.5Mbps per the S/PDIF specs. Is it possible DP is being subjected to the limits of the S/PDIF specs in the DRM driver?

Per Wikipedia:
S/PDIF can carry two channels of uncompressed PCM audio or compressed 5.1/7.1 surround sound (such as DTS audio codec); it cannot support lossless formats (other than 2ch LPCM) such as Dolby TrueHD and DTS-HD Master Audio, that require greater bandwidth[2] like that available with HDMI or DisplayPort.
Comment 102 Libin Yang 2017-08-12 02:38:22 UTC
(In reply to Jani Nikula from comment #86)
> (In reply to Libin Yang from comment #83)
> > Do you mean the test cases? If yes, I think our QA can share the test cases
> > internally. I'm not sure we can share the cases outsides.
> 
> I mean, are you running any of the HBR audio tests with external HW decoding
> over LSPCON and HDMI 2.0? For certain we aren't.

We did the HBR audio with HW decoding test 2 years ago, and the conclusion is HBR audio doesn't work. I'm not sure it is HDMI 1.4 or HDMI 2.0.

At that time, we don't have resource to implement this feature. And then last year, the HD Audio driver ownership is transferred to PEG audio team. So I'm not sure about the current status of HD Audio driver of HBR audio support. AFAIK, they didn't put much effort on HBR audio supporting.
Comment 103 Libin Yang 2017-08-12 02:50:35 UTC

> 
> If I may add, Dolby Digital and DTS passthrough works and Stereo PCM works.
> These are all limited to 1.5Mbps per the S/PDIF specs. Is it possible DP is
> being subjected to the limits of the S/PDIF specs in the DRM driver?
> 

Dolby Digital and DTS is not HBR audio and it should always work.

For this issue, I think we should make sure whether audio driver support HBR audio or not. In my opnion, both Audio driver and gfx driver need some patches to support HBR audio. I don't think only effort in gfx driver can make HBR audio work if audio driver doesn't support HBR audio.

> Per Wikipedia:
> S/PDIF can carry two channels of uncompressed PCM audio or compressed
> 5.1/7.1 surround sound (such as DTS audio codec); it cannot support lossless
> formats (other than 2ch LPCM) such as Dolby TrueHD and DTS-HD Master Audio,
> that require greater bandwidth[2] like that available with HDMI or
> DisplayPort.

Yes, this is the same status 2 years before we did the test.
Comment 104 Achilles 2017-08-12 03:21:19 UTC
(In reply to Libin Yang from comment #103)
> 
> > 
> > If I may add, Dolby Digital and DTS passthrough works and Stereo PCM works.
> > These are all limited to 1.5Mbps per the S/PDIF specs. Is it possible DP is
> > being subjected to the limits of the S/PDIF specs in the DRM driver?
> > 
> 
> Dolby Digital and DTS is not HBR audio and it should always work.
> 
> For this issue, I think we should make sure whether audio driver support HBR
> audio or not. In my opnion, both Audio driver and gfx driver need some
> patches to support HBR audio. I don't think only effort in gfx driver can
> make HBR audio work if audio driver doesn't support HBR audio.
> 
> > Per Wikipedia:
> > S/PDIF can carry two channels of uncompressed PCM audio or compressed
> > 5.1/7.1 surround sound (such as DTS audio codec); it cannot support lossless
> > formats (other than 2ch LPCM) such as Dolby TrueHD and DTS-HD Master Audio,
> > that require greater bandwidth[2] like that available with HDMI or
> > DisplayPort.
> 
> Yes, this is the same status 2 years before we did the test.
As long as we can move forward and get to a resolution is what is important. I understand the Intel dev to user ration is highly unbalanced. I want to thank you guys for the momentum this ticket has made over the course of the last few days.
Comment 105 Achilles 2017-08-13 03:23:48 UTC
Again I am not a software developer. I have co-reviewed the drm code with a colleague (retired kernel device driver developer). We see something odd in line 429-433 of hsw_audio_codec_enable. 

https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/i915/intel_audio.c

What happens if there is an interrupt? Specifically, if interrupted before the function returns, does initialization actually complete? Users complaints are "no audio passthrough/bitstreaming". Is there a 1:1 relationship to the ELD write address?

Apologies if we are way off base here.
Comment 106 Johnny Chen 2017-08-14 07:46:59 UTC
(In reply to Jani Nikula from comment #100)
> I was trying to say that i915 *always* uses PCON mode, and never LS mode,
> regardless of the sink or video mode. But apparently that is not a factor
> here.

Hi Jani Nikula ,

Do you have any update about our issue? Thanks!!!
[APL] HDMI 2.0 port cannot pass through Dolby TrueHD and DTS-HD under Linux
Comment 107 Jani Nikula 2017-08-14 08:55:04 UTC
(In reply to Johnny Chen from comment #106)
> Hi Jani Nikula ,
> 
> Do you have any update about our issue? Thanks!!!
> [APL] HDMI 2.0 port cannot pass through Dolby TrueHD and DTS-HD under Linux

See the comments above. The updates are all there. Pestering developers on the bugzilla like this is not helpful. I'm not even working on the issue.

If you have some sort of support arrangement with Intel, please escalate the bug via your support channels. Otherwise, this is just one bug among others (currently 300+ bugs).
Comment 108 Jani Nikula 2017-08-17 08:28:47 UTC
(In reply to Igor Mammedov from comment #98)
> it doesn't help (applied both comment 93 and this patch)

The intention was to try one patch at a time, *not* both at the same time.
Comment 109 hero stark 2017-08-23 02:31:41 UTC
(In reply to Jani Nikula from comment #108)
> (In reply to Igor Mammedov from comment #98)
> > it doesn't help (applied both comment 93 and this patch)
> 
> The intention was to try one patch at a time, *not* both at the same time.

Hi Jani,
Due to I use asustor nas AS6404T. But I cannot use kodi passthrough via parades 176 hdmi 2.0 output True-HD & DTS-MA. Can you help us resolve i915 driver issue? 
This helpful our users.
Thank you!!!
Comment 110 Ramesh Babu 2017-08-23 02:32:09 UTC
Created attachment 133708 [details]
attachment-21387-0.html

Hello,

I'm OOO on ww33.1 and Ww33.2 is India Site holiday.
Expect delay in response to your emails.

For urgent issues, reachable on phone.

Thanks
Ramesh
Comment 111 chrisk2305 2017-08-23 05:11:03 UTC
(In reply to hero stark from comment #109)
> (In reply to Jani Nikula from comment #108)
> > (In reply to Igor Mammedov from comment #98)
> > > it doesn't help (applied both comment 93 and this patch)
> > 
> > The intention was to try one patch at a time, *not* both at the same time.
> 
> Hi Jani,
> Due to I use asustor nas AS6404T. But I cannot use kodi passthrough via
> parades 176 hdmi 2.0 output True-HD & DTS-MA. Can you help us resolve i915
> driver issue? 
> This helpful our users.
> Thank you!!!

This is not helpful at all in the bug list. See the comment from Jani just two posts above:

See the comments above. The updates are all there. Pestering developers on the bugzilla like this is not helpful. I'm not even working on the issue.

If you have some sort of support arrangement with Intel, please escalate the bug via your support channels. Otherwise, this is just one bug among others (currently 300+ bugs).
Comment 112 dCrypt 2017-09-02 11:27:22 UTC
There's a patch here 

https://bugs.freedesktop.org/show_bug.cgi?id=101583#c28

that possibly solves the problem with HD Audio passthrough.

while I figure out how to test it, maybe there is someone who can test.

BR
Comment 113 Dennis_digital-words.de 2017-09-02 13:09:46 UTC
I have the hardware to test, but I do not have the knowledge to apply the patch.

Can anybody help?
Comment 114 Peter Frühberger 2017-09-02 17:51:03 UTC
If you are running Ubuntu, you can try: http://fritsch.fruehberger.net/kernel/?C=M;O=D - download the latest image available there which has the patch, that was referenced, included.

I did not test this build as I don't have the time to do so.
Comment 115 chrisk2305 2017-09-04 15:06:01 UTC
These are the Results with LSPCON Converter Chip:

- HDMI 2.0 is enumerated as DP
- HD Audio bit streaming/passthrough does not work
Comment 116 Jani Nikula 2017-09-06 10:26:08 UTC
(In reply to chrisk2305 from comment #115)
> - HDMI 2.0 is enumerated as DP

This is expected, because to the driver, it *is* DP. It's a DP->HDMI 2.0 converter.
Comment 117 christian.d.dietrich 2017-09-12 20:46:45 UTC
Using Kernel 4.13.1 with Joseph Nuzman patch on ASRock J3455-ITX (MCDP2800 LSPCon), HD audio passthrough (DTS-HD/Dolby TrueHD) still does not work. (Garbage output)
Comment 118 Subhransu 2017-09-19 15:24:39 UTC
Created attachment 134341 [details] [review]
hbr compressed audio fix by programming ICT bits

Attached is a patch which fixes the HBR compressed audio playback issue. Tested with below command and also tested with Kodi on ubuntu:

aplay -D 'hdmi:CARD=PCH,DEV=0,AES0=0x6' -c8 -fs16_le -r192000 thd.spdif
Comment 119 Subhransu 2017-09-19 15:25:48 UTC
Created attachment 134342 [details] [review]
hbr compressed audio fix by programming ICT bits

Attached is a patch which fixes the HBR compressed audio playback issue. Tested with below command and also tested with Kodi on ubuntu:

aplay -D 'hdmi:CARD=PCH,DEV=0,AES0=0x6' -c8 -fs16_le -r192000 thd.spdif
Comment 120 Peter Frühberger 2017-09-19 15:41:56 UTC
Thank you very much!

Tested (shorty) with 4.14-rc1 drm intel nightly + your patch. Tested DTS-X, DTS-HD, TrueHD. All working.

I tested it in 1080p24 / 1080p50 and also in 2160p50 and 2160p24 - really nice work.
Comment 121 Jani Nikula 2017-09-20 12:22:25 UTC
(In reply to christian.d.dietrich from comment #117)
> Using Kernel 4.13.1 with Joseph Nuzman patch on ASRock J3455-ITX (MCDP2800
> LSPCon), HD audio passthrough (DTS-HD/Dolby TrueHD) still does not work.
> (Garbage output)

A version of Joseph's patch has been applied to drm-tip, and should fix a class of DP audio problems, including LSPCON DP->HDMI:

commit d81fb7fd9436e81fda67e5bc8ed0713aa28d3db2
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Tue Sep 19 18:38:13 2017 +0300

    drm/i915: always update ELD connector type after get modes

Subhransu, has Sriram's patch been submitted upstream? What's the status?
Comment 122 Subhransu 2017-09-20 12:31:13 UTC
(In reply to Jani Nikula from comment #121)
> (In reply to christian.d.dietrich from comment #117)
> > Using Kernel 4.13.1 with Joseph Nuzman patch on ASRock J3455-ITX (MCDP2800
> > LSPCon), HD audio passthrough (DTS-HD/Dolby TrueHD) still does not work.
> > (Garbage output)
> 
> A version of Joseph's patch has been applied to drm-tip, and should fix a
> class of DP audio problems, including LSPCON DP->HDMI:
> 
> commit d81fb7fd9436e81fda67e5bc8ed0713aa28d3db2
> Author: Jani Nikula <jani.nikula@intel.com>
> Date:   Tue Sep 19 18:38:13 2017 +0300
> 
>     drm/i915: always update ELD connector type after get modes
> 
> Subhransu, has Sriram's patch been submitted upstream? What's the status?

Yes, Takashi has applied the patch but not sure in which branch.

http://mailman.alsa-project.org/pipermail/alsa-devel/2017-September/125710.html
Comment 123 Kevin Hekert 2017-09-20 14:41:41 UTC
Tested on Ubuntu 16.04 - 4.14.0

Hardware:
NUC 6CAYH. TrueHD Works, Dolby DTS HD Works. No hardware to test DtsX or 4K.
Comment 124 Peter Frühberger 2017-09-20 16:44:13 UTC
After gathering some feedback from LE and kodi users it seems, like that:

- it works in general, but
- if you use "Adjust Refreshrate to match video", a kodi setting to basically call xrandr -r $fps" of video, then HBR does not work and even seems to confuse the complete ELD / audio output (reboot is needed).
- it seems that this also somehow kills the "speaker mapping", on my setup for example the LFE is then output on the RR, you can verify this with:
speaker-test -c8 -s 8 -D plughw:0,3 (works as it should, but after getting "confused" LFE ends somewhere).

I think we should track this on a separate issue, right?

@Subhransu: As you test with kodi and also on Ubuntu, could you please enable this setting? It's under "Settings -> Player", it is called: "Adjust display refresh rate" and can be toggled enabled. 

Sidenote: Don't enable the setting below it "Sync playback to display" as this would disable PT right away, as Audio would be resampled so that we can nicely clock with vertical blank sync.
Comment 125 christian.d.dietrich 2017-09-20 16:53:57 UTC
Using Kernel 4.13.3 with Sriram Periyasamy patch on ASRock J3455-ITX (MCDP2800 LSPCon), HD audio passthrough (DTS-HD/Dolby TrueHD) works flawlessly. Thanks!

Sriram Periyasamy patch = HD audio works
Joseph Nuzman patch = HD audio does not work

> - if you use "Adjust Refreshrate to match video", a kodi setting to basically call xrandr 

This works for me (Kodi 17.4)! 

2160p60 > 2160p23.98 works (/w Dolby True HD)
1080p60 > 1080p23.98 works (/w Dolby True HD)

Kodi log line:

NOTICE: Display resolution ADJUST : DP2: 3840x2160 @ 23.98Hz (32) (weight: 0.000)
NOTICE: Display resolution ADJUST : DP2: 1920x1080 @ 23.98Hz (24) (weight: 0.000)
Comment 126 Peter Frühberger 2017-09-20 16:56:47 UTC
Sriram Periyasamy patch = HD audio works
Joseph Nuzman patch = HD audio does not work

both are needed, while Joseph's patch does NOT fix hbr audio, it was not meant to do so. Only the other patch, setting the HBR bit fixes this.

Okay - it seems there are different race conditions going on :-). Did you update your ASrock's firmware or something?

Let's wait for someone official to say us: how we best track these new issues to not spam whole bugzilla :-)
Comment 127 christian.d.dietrich 2017-09-20 17:07:25 UTC
(In reply to Peter Frühberger from comment #126)
> Okay - it seems there are different race conditions going on :-). Did you
> update your ASrock's firmware or something?

ASRock BIOS 1.30 / MegaChips LSPCon firmware 1.66 (from Intel)
Comment 128 Jani Nikula 2017-09-21 08:45:03 UTC
I'm closing this bug as fixed by

commit 5a5d718f952b55e7fa96bfaf6f31f2c08babd77b
Author: Sriram Periyasamy <sriramx.periyasamy@intel.com>
Date:   Tue Sep 19 17:25:05 2017 -0500

    ALSA: hda - program ICT bits to support HBR audio

in for-linus branch of Takashi's sound tree [1]. Thanks for the report, and persisting with the debugging!

I'm afraid I have no idea when that is going to hit Linus' upstream, and it also hasn't been tagged Cc: stable to have it backported to earlier kernels. You'll need to talk to Takashi and friends about that.

As to the other and remaining issues such as ones reported by Peter in comment #124, please file fresh reports for them, one bug per issue. Please cite this bug if the issues are related to HBR audio. Please mention LSPCON if it's related to LSPCON.

Thanks again.


[1] git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
Comment 129 Jani Nikula 2017-09-21 08:50:14 UTC
(In reply to Jani Nikula from comment #128)
> As to the other and remaining issues such as ones reported by Peter in
> comment #124, please file fresh reports for them, one bug per issue. Please
> cite this bug if the issues are related to HBR audio. Please mention LSPCON
> if it's related to LSPCON.

For background, should anyone care, any developer starting to read a 125+ comment bug report with all the detours and conflated issues and out-of-office autoreplies is going to get discouraged and demotivated off the bat. If the first description of a new bug report is good, we can get straight at the problem from the start.
Comment 130 Jakub 2017-09-23 00:52:02 UTC
Hi, did anyone test Dolby Digital Plus (E-AC3)? Bitstream of DD+ does not work, everything else DTS-HD, DOLBY TRUE-HD etc does... Just let you know.
Comment 131 Ramesh Babu 2017-09-23 00:52:28 UTC
Created attachment 134445 [details]
attachment-3824-0.html

Hello,

I'm OOO till Ww35.2. Will be back to work on Ww35.3.

Coverage:

Chrome Programs: Subhransu Prusty
Intel-Next & Upstream Kernel: Koul, Vinod
Icelake & CNL: R, Dharageswari
Sue Creek: Kp, Jeeja

Thanks
Ramesh
Comment 132 Peter Frühberger 2017-09-23 05:52:33 UTC
@Jakob: Works as it should. DD+ on my AVR screen. Btw. kodi sends EAC3 with 192 khz 2 channels. So no HBR needed. Please open a new bug. This one is closed and EAC3 is offtopic.
Comment 133 Jakub 2017-09-23 12:45:36 UTC
Peter Frühberger - 5.1 DD+ does not work on my Marantz SR 8002(DD+ compatible) with Kaby Lake NUC, with Skylake NUC it does. I will ask some one else to open new bug, it will be better, I am newbie at this...
Comment 134 Stan Ka 2017-09-25 09:10:50 UTC
(In reply to Subhransu from comment #119)
> Created attachment 134342 [details] [review] [review]
> hbr compressed audio fix by programming ICT bits
> 
> Attached is a patch which fixes the HBR compressed audio playback issue.
> Tested with below command and also tested with Kodi on ubuntu:
> 
> aplay -D 'hdmi:CARD=PCH,DEV=0,AES0=0x6' -c8 -fs16_le -r192000 thd.spdif

Hello,

Very good infromation, unfortunately I am not that skilled to implement your solution in my Ubuntu 16.04.

Could you be so kind and give me how to implement mentioned patch ?

Thank yo very much in advance.
Comment 135 Jakub 2017-09-28 20:35:54 UTC
After updating HDMI FW to 1.66 under windows, everything works just fine including DD+. I missed this, so maybe it will helps to someone...
Comment 136 vinod.koul 2017-09-28 20:36:07 UTC
Created attachment 134555 [details]
attachment-17386-0.html

Thanks for your email

I am on vacation till Oct 7th
Please expect delayed response.

Regards
--
~Vinod
Comment 137 Ramesh Babu 2017-09-28 20:36:12 UTC
Created attachment 134556 [details]
attachment-17443-0.html

Hi


I'm OOO till Ww41.3. Will be back to work on Ww41.4.

Please note that Ww39.5 and Ww40.1 are site holiday.

Coverage:

Chrome Programs: Subhransu Prusty
Intel-Next & Upstream Kernel:  Subhransu Prusty
Sue Creek: Kp, Jeeja
Icelake: R, Dharageswari

Thanks
Ramesh


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.