Bug 98797

Created attachment 128088 [details]
dmesg + lsmod

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

on latest kernel drm-intel drm-intel-nightly: 2016y-11m-21d-18h-22m-22s
commit	eeec5e7742b23082dd20523c8baa08fe495175e4

dmesg log:
http://sprunge.us/DPGj

Created attachment 128144 [details]
dmesg with drm.debug=14

Created attachment 128145 [details]
dmesg with drm.debug=14 (fix, correct one) kernel 4.6rc6

Adding Libin for audio.

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.

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 ...

what about that info ? 
http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/?id=433968da4d93a194b79da552f4ca707f979ef33b

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

(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.

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.

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

on other mainboard same problem and on miniPC Asus Vivo based on Skylake so problem is bigger

on other mainboard same problem and on miniPC Asus Vivo based on Skylake so problem is bigger

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.

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

anyone looking in this ticket ? i dont know what more we can delivery ..

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.

add Vinod.

Hi Vinod,

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

Thanks,
Libin

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

Created attachment 128891 [details]
Datasheet of MCDP28x0p

Comment on attachment 128891 [details]
Datasheet of MCDP28x0p

Please do not attach documents that can't be freely distributed.

The content of attachment 128891 [details] has been deleted for the following reason:

proprietary information is contained!

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).

Just to add that this issue also affects Asrock J4205 mobo, Fedora 25, Kernel 4.9.5

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.

Please try current drm-tip branch of https://cgit.freedesktop.org/drm-tip

Hi Jani,

sadly no change with this kernel. Find attached the dmesg output from the start.

Created attachment 129658 [details]
dmesg output of drm-tip

Is there anything I can provide to get the bug away from NEEDINFO? If yes, please tell us.

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.

Created attachment 129729 [details]
attachment-24995-0.html

Thanks for your email

I am attending ELC-NA
Please expect delayed response.

Regards
--
~Vinod

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.

Had the same problem with miniDP1.2->HDMI2.0 adapter on several NUC models and NUC6i7KYK has the same issue. Is it firmware related?

(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?

I did upgrade the firmware of the MCDP2800 LSPCon on my Apollo Lake NUC (NUC6CAYH) to 1.61, but the problem seems to persist.

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.

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

Any news about this problem?

Do you need more specific information? Please just let me know.

I think we got good information here

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.

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.

neither with fw 1.66

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

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

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

(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.

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)

The issue persists with same symptomes running drm-tip from yesterday. Anything else we should try?

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.

...

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.

MCDP28x0 DisplayPort1.2a-to-HDMI 2.0 Converter

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

...

(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..

(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.

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

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

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.

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)

- 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.

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.

(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.

(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).

(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?

*** Bug 101056 has been marked as a duplicate of this bug. ***

*** Bug 101835 has been marked as a duplicate of this bug. ***

(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.

(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.

(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)

>> 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.

(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

(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.

(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?

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.

(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.

(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.

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

@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.

*** Bug 101835 has been marked as a duplicate of this bug. ***

(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.

(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

(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

(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

(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

*** Bug 101835 has been marked as a duplicate of this bug. ***

(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, 
 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!!!

(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.

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.

just try in Kodi. And yes it works in Windows.

(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?

(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.

(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);

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;

(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.

(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.

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.
>
>

(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.

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

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.

(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.

(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.

> 
> 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.

(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.

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.

(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

(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).

(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.

(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!!!

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

(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).

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

I have the hardware to test, but I do not have the knowledge to apply the patch.

Can anybody help?

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.

These are the Results with LSPCON Converter Chip:

- HDMI 2.0 is enumerated as DP
- HD Audio bit streaming/passthrough does not work

(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.

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)

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

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

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.

(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?

(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

Tested on Ubuntu 16.04 - 4.14.0

Hardware:
NUC 6CAYH. TrueHD Works, Dolby DTS HD Works. No hardware to test DtsX or 4K.

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.

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)

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 :-)

(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)

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

(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.

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.

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

@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.

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...

(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.

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...

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

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