Bug 100279 - [i915] [SKL] sound resampling issues using HDMI output
Summary: [i915] [SKL] sound resampling issues using HDMI output
Status: REOPENED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-19 12:11 UTC by Christoph
Modified: 2019-08-05 06:13 UTC (History)
3 users (show)

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


Attachments
dmesg output (70.69 KB, text/x-log)
2017-03-19 12:51 UTC, Christoph
no flags Details
Xorg log (29.90 KB, text/x-log)
2017-03-19 12:51 UTC, Christoph
no flags Details
tarball of /proc/asound/card0 (3.40 KB, application/octet-stream)
2017-03-19 12:56 UTC, Christoph
no flags Details
dmesg output with drm debug (145.84 KB, text/x-log)
2017-10-06 20:26 UTC, Christoph
no flags Details
dmesg debug output using linux-drm-tip-git (161.94 KB, text/plain)
2018-09-11 14:39 UTC, Christoph
no flags Details
git bisect log (2.73 KB, text/plain)
2019-03-18 14:31 UTC, Christoph
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph 2017-03-19 12:11:21 UTC
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.
Comment 1 Tom Yan 2017-03-19 12:45:42 UTC
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.
Comment 2 Christoph 2017-03-19 12:51:06 UTC
Created attachment 130309 [details]
dmesg output
Comment 3 Christoph 2017-03-19 12:51:29 UTC
Created attachment 130310 [details]
Xorg log
Comment 4 Christoph 2017-03-19 12:56:03 UTC
Created attachment 130311 [details]
tarball of /proc/asound/card0
Comment 5 keqiao 2017-06-22 07:45:52 UTC
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~
Comment 6 Elizabeth 2017-06-23 23:03:28 UTC
Adding tag into "Whiteboard" field - ReadyForDev
*Status is correct
*Platform is included
*Feature is included
*Priority and Severity correctly set
*Logs included
Comment 7 Elizabeth 2017-08-24 17:55:13 UTC
(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.
Comment 8 Elizabeth 2017-10-06 15:18:17 UTC
Sorry for pestering. Any new on this?
Comment 9 Christoph 2017-10-06 15:31:36 UTC
Hello Elizabeth,

I still get the same results for the two speaker-test commands on linux 4.13.3.
What information do you need?
Comment 10 Elizabeth 2017-10-06 19:58:21 UTC
(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~
Comment 11 Christoph 2017-10-06 20:26:16 UTC
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.
Comment 12 Jani Saarinen 2018-03-29 07:11:57 UTC
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.
Comment 13 Jani Saarinen 2018-04-23 08:21:16 UTC
Closing, please re-open if still occurs.
Comment 14 Christoph 2018-04-27 15:48:32 UTC
The described behavior still occurs with linux 4.16.4 (archlinux).
Comment 15 Lakshmi 2018-09-11 09:09:05 UTC
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.
Comment 16 Christoph 2018-09-11 14:39:54 UTC
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.
Comment 17 Ida 2019-03-15 10:58:20 UTC
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.
Comment 18 Christoph 2019-03-18 14:30:50 UTC
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.
Comment 19 Christoph 2019-03-18 14:31:40 UTC
Created attachment 143725 [details]
git bisect log
Comment 20 Lakshmi 2019-07-15 06:18:44 UTC
(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?
Comment 21 Libin Yang 2019-07-15 08:02:10 UTC
@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.
Comment 22 Libin Yang 2019-08-05 06:13:40 UTC
The test is OK on my platform. I think maybe we need a quirk for the exceptions?


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.