Bug 75038 - [HSW HDMI] HD Audio with 44.1 khz not working when refreshrate > 30hz
Summary: [HSW HDMI] HD Audio with 44.1 khz not working when refreshrate > 30hz
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: All Linux (All)
: medium normal
Assignee: Mengdong Lin
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
: 75037 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-02-15 22:28 UTC by sraptor
Modified: 2017-07-24 22:55 UTC (History)
6 users (show)

See Also:
i915 platform: HSW
i915 features: display/audio


Attachments
here is the log file (52.30 KB, text/plain)
2014-02-15 22:29 UTC, sraptor
no flags Details
output of dmesg (134.08 KB, text/plain)
2015-02-18 06:53 UTC, Alex Shturm
no flags Details
drm/i915: use mode->crtc_clock instead of mode->clock for hdmi audio config (1.26 KB, patch)
2015-02-26 13:47 UTC, Jani Nikula
no flags Details | Splinter Review
drm/i915: use mode->crtc_clock instead of mode->clock for hdmi audio config (1.26 KB, patch)
2015-05-28 14:53 UTC, Jani Nikula
no flags Details | Splinter Review
Feejus journalctl -a (27.89 KB, application/bzip2)
2015-06-02 20:22 UTC, Peter Frühberger
no flags Details

Description sraptor 2014-02-15 22:28:07 UTC
When playing audio on my "avr name here" it does not output any sound, when refreshrate is > 30hz and samplerate is 44.1 khz.

It works fine for 48 khz. Furthermore all passtrough formats are working. I am running xbmc on OpenELEC.
According to my AVR pioneer SC-72 or AVR pioneer vsx-1021 this is a problem with setting some registers correctly. I sadly have no clue of the internals, but this bug is a major showstopper on my intel nuc setup.
Comment 1 sraptor 2014-02-15 22:29:26 UTC
Created attachment 94134 [details]
here is the log file
Comment 2 Chris Wilson 2014-02-21 22:19:25 UTC
*** Bug 75037 has been marked as a duplicate of this bug. ***
Comment 3 Jani Nikula 2014-09-05 12:23:56 UTC
sraptor, the bug seems to have been neglected. Sorry. Please try a more recent kernel, preferrably upstream v3.17-rc or drm-intel-nightly branch of [1]. If the problem persists, please attach dmesg with drm.debug=0xe all the way from boot to the problem. Thanks.

[1] http://cgit.freedesktop.org/drm-intel
Comment 4 Jesse Barnes 2014-12-04 21:09:13 UTC
I guess this must have been fixed?  Please re-open if not and we can get our audio guys to take a look.  Sounds like we're not programming something right for that sample rate as you said.
Comment 5 Peter Frühberger 2015-02-17 08:24:13 UTC
This bug still exists and most of the time users with Denon AVRs are hit.

I try to get some users here posting the relevant logs.
Comment 6 Jani Nikula 2015-02-17 08:38:30 UTC
Peter, please try kernel v3.19 - or even drm-intel-nightly branch from http://cgit.freedesktop.org/drm-intel. Please attach dmesg with drm.debug=14 module parameter set.

Mengdong, do you have any fresh ideas to try?
Comment 7 Peter Frühberger 2015-02-17 16:29:05 UTC
Hi Jani,

if it was my systems - you'd have the relevant logfiles by now. But those aren't. I am trying to get the affected OpenELEC / kodi users - which file bug reports with our software - to this bugtracker.

Give them some time, please.
Comment 8 Alex Shturm 2015-02-18 04:43:55 UTC
Collected data is referenced in this thread:
http://forum.kodi.tv/showthread.php?tid=218677
Comment 9 Alex Shturm 2015-02-18 06:53:10 UTC
Created attachment 113599 [details]
output of dmesg
Comment 10 Alex Shturm 2015-02-18 07:51:47 UTC
speaker-test -D plughw:0,3 -r 44100 -- does not work
speaker-test -D plughw:0,3 -r 48000 -- works
speaker-test -D plughw:0,3 -r 44100 -- now works !!

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: HDMI [HDA Intel HDMI], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: PCH [HDA Intel PCH], device 0: ALC283 Analog [ALC283 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
Comment 11 Jani Nikula 2015-02-18 12:53:22 UTC
(In reply to Alex Shturm from comment #10)
> speaker-test -D plughw:0,3 -r 44100 -- does not work
> speaker-test -D plughw:0,3 -r 48000 -- works
> speaker-test -D plughw:0,3 -r 44100 -- now works !!
> 
> $ aplay -l
> **** List of PLAYBACK Hardware Devices ****
> card 0: HDMI [HDA Intel HDMI], device 3: HDMI 0 [HDMI 0]
> Subdevices: 1/1
> Subdevice #0: subdevice #0
> card 0: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1]
> Subdevices: 1/1
> Subdevice #0: subdevice #0
> card 1: PCH [HDA Intel PCH], device 0: ALC283 Analog [ALC283 Analog]
> Subdevices: 1/1
> Subdevice #0: subdevice #0

Mengdong, to me this smells more like a problem in the audio than display driver.
Comment 12 sraptor 2015-02-19 02:50:35 UTC
I have problems, also. I will send the log this weekend
Comment 13 Alex Shturm 2015-02-24 17:21:58 UTC
Can I hope to have this fixed anytime soon, or I better start shopping for a new receiver?
Comment 14 Jani Nikula 2015-02-26 08:59:27 UTC
(In reply to Alex Shturm from comment #10)
> speaker-test -D plughw:0,3 -r 44100 -- does not work
> speaker-test -D plughw:0,3 -r 48000 -- works
> speaker-test -D plughw:0,3 -r 44100 -- now works !!

Please attach tools/intel_audio_dump output after *each* step.

The tool is part of the Intel gpu tools package http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/
Comment 15 Jani Nikula 2015-02-26 13:47:14 UTC
Created attachment 113846 [details] [review]
drm/i915: use mode->crtc_clock instead of mode->clock for hdmi audio config

A patch worth trying at least.
Comment 16 Mengdong Lin 2015-02-26 15:10:23 UTC
This issue may be (In reply to Alex Shturm from comment #10)
> speaker-test -D plughw:0,3 -r 44100 -- does not work
> speaker-test -D plughw:0,3 -r 48000 -- works
> speaker-test -D plughw:0,3 -r 44100 -- now works !!
> 
> $ aplay -l
> **** List of PLAYBACK Hardware Devices ****
> card 0: HDMI [HDA Intel HDMI], device 3: HDMI 0 [HDMI 0]
> Subdevices: 1/1
> Subdevice #0: subdevice #0
> card 0: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1]
> Subdevices: 1/1
> Subdevice #0: subdevice #0
> card 1: PCH [HDA Intel PCH], device 0: ALC283 Analog [ALC283 Analog]
> Subdevices: 1/1
> Subdevice #0: subdevice #0

Hi Alex, could you try another HDMI or DisplayPort monitor?

IIFC, we met a similar issue before for a specific monitor before:
48000 ... does not work
44100 ... works
48000 ... now works

But other monitor does not have this problem with the same kernel and the display audio register dump are same. So we could not give a fix in the audio driver. I'll try to check that if that bug was fixed with gfx driver update.
Comment 17 Carl Adams 2015-02-26 17:21:02 UTC
I believe I am seeing a similar issue.  For me, HD audio passthrough sometimes works, sometimes doesn't.  When it's not working, receiver is still telling me it's getting the correct audio stream (DTS-HD or TrueHD), but I only get silence.

I first encountered the issue using Kodi (see http://forum.kodi.tv/showthread.php?tid=219048), but I can also reproduce the issue with aplay with something like this:
    aplay -D 'hdmi:CARD=PCH,DEV=1,AES0=2' -c8 -fs16_le -r19200 truehd-sample.spdif

It's random enough that I would have a hard time saying what causes one invocation to work while the next one may fail.

System details:
Fedora 21 x86_64 with all updates
IvyBridge with HD4000 graphics (i7-3770), Denon-AVR2310ci, (Samsung TV, but that's only connected through the Denon)

Anything I can do to help?
Comment 18 Alex Shturm 2015-02-27 05:34:28 UTC
(In reply to Jani Nikula from comment #14)
> (In reply to Alex Shturm from comment #10)
> > speaker-test -D plughw:0,3 -r 44100 -- does not work
> > speaker-test -D plughw:0,3 -r 48000 -- works
> > speaker-test -D plughw:0,3 -r 44100 -- now works !!
> 
> Please attach tools/intel_audio_dump output after *each* step.
> 
> The tool is part of the Intel gpu tools package
> http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/

http://paste.ubuntu.com/10442019/   -- before first command (44100)
http://paste.ubuntu.com/10442032/   -- after first command (44100)
http://paste.ubuntu.com/10442033/   -- after second command (48000)
http://paste.ubuntu.com/10442034/   -- after third command (44100)
Comment 19 Alex Shturm 2015-02-27 05:36:03 UTC
(In reply to Jani Nikula from comment #15)
> Created attachment 113846 [details] [review] [review]
> drm/i915: use mode->crtc_clock instead of mode->clock for hdmi audio config
> 
> A patch worth trying at least.

I'm not sure what to do with it.
If I need to rebuild something, I need instructions.
Comment 20 Alex Shturm 2015-02-27 05:49:06 UTC
(In reply to Mengdong Lin from comment #16)

> Hi Alex, could you try another HDMI or DisplayPort monitor?
> 
> IIFC, we met a similar issue before for a specific monitor before:
> 48000 ... does not work
> 44100 ... works
> 48000 ... now works
> 
> But other monitor does not have this problem with the same kernel and the
> display audio register dump are same. So we could not give a fix in the
> audio driver. I'll try to check that if that bug was fixed with gfx driver
> update.

I connected HDMI directly to my TV (Mitsubishi WD-82737), rebooted NUC, and run these commands again. I could hear the sound each time, so it works correctly when connected directly to TV.

Do you want me to collect any additional information when NUC is connected directly to TV?
Comment 21 Peter Frühberger 2015-02-27 19:09:51 UTC
@Alex Shturm:

I created Ubuntu kernel packages with the provided patch for you. You will need to download _all_ of those three following .deb files. One file is a bumped firmware to make sure everything that might be needed is in:

https://dl.dropboxusercontent.com/u/55728161/linux-image-3.19.0-intel-fix1%2B_3.19.0-intel-fix1%2B-10.00.Custom_amd64.deb

https://dl.dropboxusercontent.com/u/55728161/linux-headers-3.19.0-intel-fix1%2B_3.19.0-intel-fix1%2B-10.00.Custom_amd64.deb

https://launchpad.net/ubuntu/+source/linux-firmware/1.141/+build/6734508/+files/linux-firmware_1.141_all.deb



After download, you can install those, by doing:
sudo dpkg -i *deb

Afterwards: sudo update-grub

Now reboot and verify you are running this version.
Comment 22 Alex Shturm 2015-02-28 04:52:30 UTC
(In reply to Peter Frühberger from comment #21)
> @Alex Shturm:
> 
> I created Ubuntu kernel packages with the provided patch for you. You will
> need to download _all_ of those three following .deb files. One file is a
> bumped firmware to make sure everything that might be needed is in:
> 
> https://dl.dropboxusercontent.com/u/55728161/linux-image-3.19.0-intel-
> fix1%2B_3.19.0-intel-fix1%2B-10.00.Custom_amd64.deb
> 
> https://dl.dropboxusercontent.com/u/55728161/linux-headers-3.19.0-intel-
> fix1%2B_3.19.0-intel-fix1%2B-10.00.Custom_amd64.deb
> 
> https://launchpad.net/ubuntu/+source/linux-firmware/1.141/+build/6734508/
> +files/linux-firmware_1.141_all.deb
> 
> 
> 
> After download, you can install those, by doing:
> sudo dpkg -i *deb
> 
> Afterwards: sudo update-grub
> 
> Now reboot and verify you are running this version.

It did not help - behavior has not changed.

I'm not sure everything was built/installed cleanly. Can you check, please?

output of "sudo dpkg -i *deb" - with some errors:
http://paste.ubuntu.com/10461697/

contents of /var/lib/dkms/nvidia-304/304.125/build/make.log mentioned in the out of previous command
http://paste.ubuntu.com/10461699/

output of "uname -a" after reboot
Linux kodi 3.19.0-intel-fix1+ #2 SMP Fri Feb 27 19:49:15 CET 2015 x86_64 x86_64 x86_64 GNU/Linux
Comment 23 Peter Frühberger 2015-02-28 07:12:27 UTC
Looks oky.

The failure is the nvidia binary blob which does not build with 3.19 kernel. Please provide all the logs that are needed.

drm.debug=0xe then do the aplay commands and see what you get. Also do them with 30hz and see what happens. Make sure to capture them in the dmesg log.
Comment 24 Alex Shturm 2015-03-01 06:27:26 UTC
(In reply to Peter Frühberger from comment #23)

> drm.debug=0xe then do the aplay commands and see what you get. Also do them
> with 30hz and see what happens. Make sure to capture them in the dmesg log.

dmesg output: http://paste.ubuntu.com/10481806/

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: HDMI [HDA Intel HDMI], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: PCH [HDA Intel PCH], device 0: ALC283 Analog [ALC283 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

As I said before, I observe no changes with this patch:
speaker-test -D plughw:0,3 -r 44100 -- does not work
speaker-test -D plughw:0,3 -r 48000 -- works
speaker-test -D plughw:0,3 -r 44100 -- now works

I'm kind of confused as to in what order to capture which outputs.
Please advise about exact sequence and I'mm gladly do it.

Also, let me know whether I should log into desktop (lubuntu) directly for these tests, or let Kodi start, and then exit from it and run the tests while being in the login screen.
(I'm opening terminal and ssh connect to NUC from another computer in all cases anyway.)
Comment 25 Peter Frühberger 2015-03-01 07:08:40 UTC
Hi,

that bug has nothing to do with kodi, it looks like a kernel / ALSA issue. Please use a normal desktop session and just play with the aplay / speaker-test commands, while changing the sample rate (as you already do).
Comment 26 Alex Shturm 2015-03-03 07:32:30 UTC
(In reply to Peter Frühberger from comment #25)
> Hi,
> 
> that bug has nothing to do with kodi, it looks like a kernel / ALSA issue.
> Please use a normal desktop session and just play with the aplay /
> speaker-test commands, while changing the sample rate (as you already do).

changed login to lubuntu
<<reboot>>
shturm@kodi:~$ dmesg | pastebinit
http://paste.ubuntu.com/10512058/
shturm@kodi:~$ speaker-test -D plughw:0,3 -r 44100
... sound ON ...

<<reboot>>
shturm@kodi:~$ DISPLAY=:0 /usr/lib/kodi/kodi-xrandr --output HDMI1 --mode 0xae
shturm@kodi:~$ dmesg | pastebinit
http://paste.ubuntu.com/10512077/
shturm@kodi:~$ speaker-test -D plughw:0,3 -r 44100
... sound ON ...

<<reboot>>
shturm@kodi:~$ DISPLAY=:0 /usr/lib/kodi/kodi-xrandr --output HDMI1 --mode 0x48
shturm@kodi:~$ dmesg | pastebinit
http://paste.ubuntu.com/10512107/
shturm@kodi:~$ speaker-test -D plughw:0,3 -r 44100
... sound ON ...

<<reboot>>
shturm@kodi:~$ DISPLAY=:0 /usr/lib/kodi/kodi-xrandr --output HDMI1 --mode 0x48
shturm@kodi:~$ DISPLAY=:0 /usr/lib/kodi/kodi-xrandr --output HDMI1 --mode 0xae
shturm@kodi:~$ dmesg | pastebinit
http://paste.ubuntu.com/10512159/
shturm@kodi:~$ speaker-test -D plughw:0,3 -r 44100
.. sound ON ...
shturm@kodi:~$ DISPLAY=:0 /usr/lib/kodi/kodi-xrandr --output HDMI1 --mode 0xae
shturm@kodi:~$ speaker-test -D plughw:0,3 -r 44100
... sound OFF ...
shturm@kodi:~$ dmesg | pastebinit
http://paste.ubuntu.com/10512161/
shturm@kodi:~$ speaker-test -D plughw:0,3 -r 48000
... sound ON ...
shturm@kodi:~$ speaker-test -D plughw:0,3 -r 44100
... sound ON ...
shturm@kodi:~$ dmesg | pastebinit
http://paste.ubuntu.com/10512177/

If you want me to run some other sequence of commands, please let me know the exact sequence.
Comment 27 Peter Frühberger 2015-03-03 07:36:03 UTC
Thanks very much. Can you test the same with "normal" xrandr?

e.g. DISPLAY=:0 xrandr --output HDMI1 --mode 0x48 ?

Also provide: DISPLAY=:0 xrandr -q | pastebinit so that we can see your modes.

From that testing here it looks like kodi's xrandr does harm - therefore please test with normal xrandr.

Thanks much again.
Comment 28 Alex Shturm 2015-03-03 07:46:07 UTC
(In reply to Peter Frühberger from comment #27)
> Thanks very much. Can you test the same with "normal" xrandr?
> 
> e.g. DISPLAY=:0 xrandr --output HDMI1 --mode 0x48 ?
> 
> Also provide: DISPLAY=:0 xrandr -q | pastebinit so that we can see your
> modes.
> 
> From that testing here it looks like kodi's xrandr does harm - therefore
> please test with normal xrandr.
> 
> Thanks much again.

<<reboot>>
shturm@kodi:~$ DISPLAY=:0 xrandr -q | pastebinit
http://paste.ubuntu.com/10512239/

Interestingly, setting the same mode twice kills the sound!
Look:

<<reboot>>
shturm@kodi:~$ DISPLAY=:0 xrandr --output HDMI1 --mode 0xae
shturm@kodi:~$ speaker-test -D plughw:0,3 -r 44100
... sound ON ...
shturm@kodi:~$ DISPLAY=:0 xrandr --output HDMI1 --mode 0xae
shturm@kodi:~$ speaker-test -D plughw:0,3 -r 44100
... sound OFF ...
shturm@kodi:~$ dmesg | pastebinit
http://paste.ubuntu.com/10512268/

<<reboot>>
shturm@kodi:~$ DISPLAY=:0 xrandr --output HDMI1 --mode 0x48
shturm@kodi:~$ speaker-test -D plughw:0,3 -r 44100
... sound ON ...
shturm@kodi:~$ DISPLAY=:0 xrandr --output HDMI1 --mode 0x48
shturm@kodi:~$ speaker-test -D plughw:0,3 -r 44100
... sound OFF ...
shturm@kodi:~$ dmesg | pastebinit
http://paste.ubuntu.com/10512300/
Comment 29 Peter Frühberger 2015-03-03 07:55:30 UTC
And for final completion:

If you do the sound test twice _without_ changing refreshrate it continues to work?
Comment 30 Alex Shturm 2015-03-03 08:01:57 UTC
(In reply to Peter Frühberger from comment #29)
> And for final completion:
> 
> If you do the sound test twice _without_ changing refreshrate it continues
> to work?

<<reboot>>
shturm@kodi:~$ DISPLAY=:0 xrandr --output HDMI1 --mode 0xae
shturm@kodi:~$ speaker-test -D plughw:0,3 -r 44100
... sound ON ...
shturm@kodi:~$ speaker-test -D plughw:0,3 -r 44100
... sound OFF ...

<<reboot>>
shturm@kodi:~$ DISPLAY=:0 xrandr --output HDMI1 --mode 0x48
shturm@kodi:~$ speaker-test -D plughw:0,3 -r 44100
... sound ON ...
shturm@kodi:~$ speaker-test -D plughw:0,3 -r 44100
... sound OFF ...
Comment 31 Peter Frühberger 2015-03-03 09:49:37 UTC
Can we conclude that every second opening of the sound device just produces no sound?
Comment 32 Jani Nikula 2015-03-03 11:41:43 UTC
I think we can conclude this is not a drm/i915 bug.
Comment 33 Feejus 2015-05-28 13:37:24 UTC
Hi, I just wanted to point out that i have the same issue.

First of all I want to thank you all for the great software and the best Media player in the world. I am running into some issues with my current hardware related to Kodi.

ZOTAC ZBOX EI750
16GB RAM
500 Gig SSD disk
Thecus 5200 Pro - NAS server - SMB enabled.
Switch - D-Link DGS-1100-24
Pioneer SC-LX57
OpenElec 5.08 - Kodi 14.x


I want to start to mention that I have had issues with Kodi with this particular hardware before. This was resolved in one of the builds after 5.0 of OpenElec. Now my issues currently is with playback of Music MP3 files. Also connection is done over HDMI however the Zotac EI750 does not have HDMI so I use a DVI --> HDMI converter. The settings in Audio Output in Kodi is as follows. I use the HDA Inte PIO SC-LX57 on HDMI #1 as the output source.

HDA Intel PIO SC-LX57 On HDMI #1
HDA Intel HDMI #0
HDA Intel HDM #2
HDA Intel PCH ID 892 Analog
HDA Intel PCH ID 892 Digital SPDIF

Issue: I have added my MP3 collection to kodi, and while my old Asrock did playback MP3 just fine with my Zotec I am not getting any sound. In this case you would think there is something wrong with my setup and here is something which does not add up. You see I have some movies / tv shows, and all of those playback just fine. I get the full Passthrough to work, I.E DolbyDigital, DTS and even True-HD / DTS-HD. Its only MP3 playback and some add-on like DI or MixCloud which does not produce any sound.

Issue was fixed by adding following advancedsettings.xml. Wanted to thank you and the community to providing this fix.

<advancedsettings>
<audio>
<minimumsamplerate>48000</minimumsamplerate>
</audio>
</advancedsettings>

Thank you
Feejus
Comment 34 Peter Frühberger 2015-05-28 13:51:39 UTC
This is not kodi's bugtracker. But thanks anyways.

Can you please add: drm.debug=0xe to the bootloader configuration in /flash reboot the machine.

(Remove the advancedsettings workaround before you start please).

After boot:

Play an mp3 (44.1 khz)

Then play something that works afterwards

After all this provide: dmesg | pastebinit or upload the dmesg output to this bugtracker.
Comment 35 Jani Nikula 2015-05-28 14:53:59 UTC
Created attachment 116118 [details] [review]
drm/i915: use mode->crtc_clock instead of mode->clock for  hdmi audio config

Just to give something to try, here's an untested shot-in-the-dark patch.
Comment 36 Peter Frühberger 2015-06-02 20:22:04 UTC
Created attachment 116253 [details]
Feejus journalctl -a

Booting with drm.debug=0xe and playing some 44.1 khz mp3.
Comment 37 Feejus 2015-06-03 12:35:36 UTC
Hi 
As part of the debug here is my findings.

44.1 kHz = No sound
48.0 kHz = Music
88.2 kHz = No sound
96.0 kHz = Music
192.0 khz = Music

I hope this helps you!

Please let me know if there is any additional details you might need or would like me to me to test. 

Thank you
Feejus
Comment 38 BBUK 2015-06-12 17:20:38 UTC
(In reply to Jani Nikula from comment #35)
> Created attachment 116118 [details] [review] [review]
> drm/i915: use mode->crtc_clock instead of mode->clock for  hdmi audio config
> 
> Just to give something to try, here's an untested shot-in-the-dark patch.

I'm new to this report but am having the same issue on a Pioneer SC-LX57 and a system running under kernel 4.0.1.

Thanks very much for the patch.  I have tried it and it unfortunately does not work in the sense that it does not appear to have done any harm but the same behaviour is apparent - no audio at 44.1kHz with refresh rate > 30Hz. 

Although I am still testing, it is possible that the patch has solved one intermittent issue I was having involving audio stuttering and an excessive number of broken pipes - I will report back on this.

In the meantime, I am set up to run/compile/test whatever - just let me know what I can do to help.
Comment 39 Jani Nikula 2015-06-15 06:40:59 UTC
This is probably the same issue as bug 90776.
Comment 40 BBUK 2015-06-16 17:52:41 UTC
(In reply to Jani Nikula from comment #39)
> This is probably the same issue as bug 90776.

Thanks for this - really helpful as it pointed me out to a pretty much perfect workaround for my use case (Kodi).

Setting the GUI resolution in Kodi to one of the CEA modes (best one in my case was 1280x720p 50Hz) solves the problem.  I also checked the DMT mode (1280x720p 60Hz) and that seemed to work too.

Note that in Kodi Blu-rays appear to play back at full resolution no matter what resolution is set for the Kodi GUI so the lower GUI resolution setting is not really a problem.

Thx again and I am still available -if needed- to do testing etc.
Comment 41 Peter Frühberger 2015-06-16 18:04:23 UTC
Erm, it's offtopic, but you are wrong ... concerning the 720p ... we only switch refreshrates, but we don't switch resolutions.
Comment 42 BBUK 2015-06-16 20:56:06 UTC
(In reply to Peter Frühberger from comment #41)
> Erm, it's offtopic, but you are wrong ... concerning the 720p ... we only
> switch refreshrates, but we don't switch resolutions.

Hah, I only checked the resolution the TV was reporting without thinking whether my receiver was doing any resolution upscaling - it was!

So perhaps not as good a workaround as I thought ...

Sorry about the OT
Comment 43 Jani Nikula 2015-10-23 09:48:47 UTC
Everything should be fixed in upstream drm-intel-nightly branch of http://cgit.freedesktop.org/drm-intel now, on their way to v4.4 kernel. If not, please reopen. Sadly for downstreams, we won't be able to backport the fixes to stable kernels. Thanks for the report.
Comment 44 Daniel Shafer 2015-11-04 23:37:08 UTC
(In reply to Jani Nikula from comment #43)
> Everything should be fixed in upstream drm-intel-nightly branch of
> http://cgit.freedesktop.org/drm-intel now, on their way to v4.4 kernel. If
> not, please reopen. Sadly for downstreams, we won't be able to backport the
> fixes to stable kernels. Thanks for the report.

Is this suppose to be working in 4.3?  Or 4.4.  I was a little confused at the comment and as 4.3 came out and the problem wasn't resolved for me.
Comment 45 Jani Nikula 2015-11-05 13:57:29 UTC
(In reply to Daniel Shafer from comment #44)
> (In reply to Jani Nikula from comment #43)
> > Everything should be fixed in upstream drm-intel-nightly branch of
> > http://cgit.freedesktop.org/drm-intel now, on their way to v4.4 kernel. If
> > not, please reopen. Sadly for downstreams, we won't be able to backport the
> > fixes to stable kernels. Thanks for the report.
> 
> Is this suppose to be working in 4.3?  Or 4.4.  I was a little confused at
> the comment and as 4.3 came out and the problem wasn't resolved for me.

We were aiming for v4.3, but unfortunately missed it. They should land in v4.4.
Comment 46 Peter Frühberger 2015-11-05 13:58:29 UTC
Hi Jani,

could you point us to the patches then I can prepare some kernel builds the users to test?
Comment 47 Joakim Birath 2015-11-10 17:51:09 UTC
Hi. This is not fixed for me. Running OpenElec 6.0.95-fritsch with 4.3.0-kernel

Logs from my Chromebox:
dmesg: http://sprunge.us/HRRL
kodi.log: http://sprunge.us/NDOQ
journalctl: http://sprunge.us/LQeS
Comment 48 Jani Nikula 2015-11-11 15:43:46 UTC
(In reply to Joakim Birath from comment #47)
> Hi. This is not fixed for me. Running OpenElec 6.0.95-fritsch with
> 4.3.0-kernel

See comment #45.
Comment 49 Jani Nikula 2015-11-11 15:46:01 UTC
(In reply to Peter Frühberger from comment #46)
> Hi Jani,
> 
> could you point us to the patches then I can prepare some kernel builds the
> users to test?

Current Linus' tree has these commits:

cb422619976f drm/i915: DocBook add i915_component.h support
3f4c90bd2031 drm/i915: add kerneldoc for i915_audio_component
7e8275c2f2bb drm/i915: set proper N/CTS in modeset
ddd621fbba35 ALSA: hda - display audio call sync_audio_rate callback
4a21ef7d1d2b drm/i915: implement sync_audio_rate callback
5334240c30cb drm/i915: Add audio sync_audio_rate callback

d5f362a7b977 drm/i915: Add locks around audio component bind/unbind
f0675d4a8ed9 drm/i915: Drop port_mst_index parameter from pin/eld callback
25adc137c546 ALSA: hda - Wake the codec up on pin/ELD notify events
45c053df5bdc ALSA: hda - allow codecs to access the i915 pin/ELD callback
51e1d83cab99 drm/i915: Call audio pin/ELD notify function
2a8ceedf7871 drm/i915: Add audio pin sense / ELD callback

Those are my rough estimate of what the needed changes are. I hope I didn't miss anything.
Comment 50 Peter Frühberger 2015-11-11 15:48:50 UTC
Thanks Jani,

I will advice users to test with 4.4-rc1 and later. That way they can actively test upcoming 4.4 release and it lowers the possibility that backports cause other issues.

Thanks again
Peter
Comment 51 Mark Wilczynski 2016-08-22 01:20:50 UTC
I'm not sure if the original bug was ever fixed since the users who reported it in this thread didn't confirm a solution.  I'm still seeing this bug exactly as described here.  The only difference for me is that I wasn't seeing the bug until I upgraded kernel from 4.1 to 4.3.  All future kernels up to 4.7 are also broken for me.

I'm using a Samsung PN51F8500 TV directly connected to a Asus Vivo Mini PC using a 2957U processor.  44.1 Khz input over HDMI works fine on this TV from a Raspberry Pi and also worked fine on the older kernels so I don't think it's the TV at fault.  44.1 Khz also works if I use my Denon AVR instead of the TV speakers (regardless of kernel).

I'm sure my debug logs will be similar to those already posted here but please let me know if you need anything specific.  Be specific on the steps because I'm not a Linux debugging expert.  Thanks.
Comment 52 Jani Nikula 2016-08-22 11:26:46 UTC
(In reply to Mark Wilczynski from comment #51)
> I'm not sure if the original bug was ever fixed since the users who reported
> it in this thread didn't confirm a solution.  I'm still seeing this bug
> exactly as described here.  The only difference for me is that I wasn't
> seeing the bug until I upgraded kernel from 4.1 to 4.3.  All future kernels
> up to 4.7 are also broken for me.
> 
> I'm using a Samsung PN51F8500 TV directly connected to a Asus Vivo Mini PC
> using a 2957U processor.  44.1 Khz input over HDMI works fine on this TV
> from a Raspberry Pi and also worked fine on the older kernels so I don't
> think it's the TV at fault.  44.1 Khz also works if I use my Denon AVR
> instead of the TV speakers (regardless of kernel).
> 
> I'm sure my debug logs will be similar to those already posted here but
> please let me know if you need anything specific.  Be specific on the steps
> because I'm not a Linux debugging expert.  Thanks.

Well, we're not sure if the bug was not fixed... ;)

Please let's give the old bugs a rest. Please file a new bug. The kernel moves too fast for any of the old logs to be useful, on the contrary the old history here may be confusing. You can reference this one from the new bug if you like. Please add drm.debug=14 module parameter, and attach dmesg all the way from boot to the problem.
Comment 53 Mark Wilczynski 2016-08-22 20:19:24 UTC
Filed a new bug here:
https://bugs.freedesktop.org/show_bug.cgi?id=97442


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.