In the current stable (4.10.3-1) and mainline (4.11.0-rc2) kernels of Arch Linux I noticed resampling issues when playing 44.1kHz audio using the HDMI output of my i915 chipset on a Asus Z170-A motherboard. This issue wasn't present in previous releases but I didn't take the time to bisect and find the relevant commit yet. In the following, hw:0,3 refers to the HDMI output of the HDA Intel PCH. speaker-test -D hw:0,3 -c 2 -r 48000 -f 440 -t sine This produduces a fine 440Hz sine wave. speaker-test -D hw:0,3 -c 2 -r 44100 -f 440 -t sine This produces a way lower frequency sound with clicking noises about twice a second. Running the same on the analog output doesn't result in any resampling issues.
Hey rio, sorry i might have misled you a bit. This is not precisely a resampling issue, but an issue on sending sound at a certain sampling rate (44.1khz, and maybe also its multiples, in this case) through hdmi. The reason I think you should file it here is because, hdmi sound works in a way that it can be affected by the display mode (resolution and refresh rate) you are with, because of some clock calculation on the signal sending. Similar issues have been seen in the past occuring in the various kms drivers (i915, radeon...). Therefore, you should attach a copy of recent dmesg and xorg log, which shows info like your cpu model (hence the gpu) and the display mode your monitor/tv is on. The dev may also want to take a look at the codec and eld files in /proc/asound/cardN.
Created attachment 130309 [details] dmesg output
Created attachment 130310 [details] Xorg log
Created attachment 130311 [details] tarball of /proc/asound/card0
I tried your commands above with latest mainline 4.12.0-rc6, but I didn't hear any clicking noises during playback. I also tried to play 44.1KHz audio streams through HDMI, also working well. Then I switched to mainline v4.11-rc2, still no issues found. I verified this issue on my SKL NUC, could you give us more descriptions about this issue in case I misunderstood. Thanks~
Adding tag into "Whiteboard" field - ReadyForDev *Status is correct *Platform is included *Feature is included *Priority and Severity correctly set *Logs included
(In reply to keqiao from comment #5) > I tried your commands above with latest mainline 4.12.0-rc6, but I didn't > hear any clicking noises during playback. I also tried to play 44.1KHz audio > streams through HDMI, also working well. > Then I switched to mainline v4.11-rc2, still no issues found. > I verified this issue on my SKL NUC, could you give us more descriptions > about this issue in case I misunderstood. Thanks~ Hello Rio, Tom, Could you please provide more information to be able to reproduce this bug? Thank you.
Sorry for pestering. Any new on this?
Hello Elizabeth, I still get the same results for the two speaker-test commands on linux 4.13.3. What information do you need?
(In reply to rio from comment #9) > Hello Elizabeth, > > I still get the same results for the two speaker-test commands on linux > 4.13.3. > What information do you need? In comment #5, Keqiao mentions he tried to reproduce the issue using the commands on comment #1 but couldn't reproduce. Could you add a more detailed description of the issue? Do you follow any additional steps to reproduce besides executing the commands? Also a dmesg and/or a kern.log with debbug information may help, just add drm.debug=0xe to the grub. (In reply to keqiao from comment #5) > I tried your commands above with latest mainline 4.12.0-rc6, but I didn't > hear any clicking noises during playback. I also tried to play 44.1KHz audio > streams through HDMI, also working well. > Then I switched to mainline v4.11-rc2, still no issues found. > I verified this issue on my SKL NUC, could you give us more descriptions > about this issue in case I misunderstood. Thanks~
Created attachment 134715 [details] dmesg output with drm debug I added a dmesg output with drm.debug=0xe enabled. To reproduce the described behaviour I just boot into my desktop environment and execute the two commands.
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Closing, please re-open if still occurs.
The described behavior still occurs with linux 4.16.4 (archlinux).
Reporter, do you still have the issue? Please try to reproduce the issue using drm-tip (https://cgit.freedesktop.org/drm-tip) and kernel parameters drm.debug=0x1e log_buf_len=4M, and if the problem persists attach the full dmesg from boot. Testing with latest drm-tip and latest logs will speed up the investigation.
Created attachment 141527 [details] dmesg debug output using linux-drm-tip-git The problem still persists. I have added a full kernel message log when running the latest drm tip kernel.
We've executed commands from the first comment on ICL-U. We do not hear any clicking noises and we do not see any distortions in waveforms in Audacity as well.
Since nobody seems to be able to reproduce this issue, after 2 years I now decided to bisect this behavior myself. The commit that introduced the issue is: https://github.com/torvalds/linux/commit/6014ac122ed081feca99217bc57b2e15c7fc1a51 Unfortunately I don't have access to the DisplayPort 1.4 specs to check if the Maud/Naud values for 44.1 kHz have been implemented correctly.
Created attachment 143725 [details] git bisect log
(In reply to Christoph from comment #18) > Since nobody seems to be able to reproduce this issue, after 2 years I now > decided to bisect this behavior myself. The commit that introduced the issue > is: > > https://github.com/torvalds/linux/commit/ > 6014ac122ed081feca99217bc57b2e15c7fc1a51 > > Unfortunately I don't have access to the DisplayPort 1.4 specs to check if > the Maud/Naud values for 44.1 kHz have been implemented correctly. @Libin, any comments from your side here?
@Christoph and @Lakshmi Thanks for figuring out the root cause of the bug. The patch "drm/i915/audio: set proper N/M in modeset" is trying to setup the M/N manually because there may be some bugs if we use HW automatically calculated value on some specific platforms. Like Keqiao's previous comments, we couldn't reproduce this bug at that time. Maybe the M/N is not accurate or maybe the new platforms have new requirement to set the M/N. I got the final M/N value from other team when I made this patch. I will check whether the value is correct or not. As I didn't work on legacy HD-audio driver for a long time, I don't have proper platforms to test now. I need to find a proper platform to reproduce this bug firstly.
The test is OK on my platform. I think maybe we need a quirk for the exceptions?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/33.
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.