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.
Created attachment 94134 [details] here is the log file
*** Bug 75037 has been marked as a duplicate of this bug. ***
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
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.
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.
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?
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.
Collected data is referenced in this thread: http://forum.kodi.tv/showthread.php?tid=218677
Created attachment 113599 [details] output of dmesg
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
(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.
I have problems, also. I will send the log this weekend
Can I hope to have this fixed anytime soon, or I better start shopping for a new receiver?
(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/
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.
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.
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?
(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)
(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.
(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?
@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.
(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
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.
(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.)
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).
(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.
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.
(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/
And for final completion: If you do the sound test twice _without_ changing refreshrate it continues to work?
(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 ...
Can we conclude that every second opening of the sound device just produces no sound?
I think we can conclude this is not a drm/i915 bug.
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
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.
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.
Created attachment 116253 [details] Feejus journalctl -a Booting with drm.debug=0xe and playing some 44.1 khz mp3.
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
(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.
This is probably the same issue as bug 90776.
(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.
Erm, it's offtopic, but you are wrong ... concerning the 720p ... we only switch refreshrates, but we don't switch resolutions.
(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
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.
(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.
(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.
Hi Jani, could you point us to the patches then I can prepare some kernel builds the users to test?
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
(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.
(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.
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
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.
(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.
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.