Bug 101347 - [DP] [BDW] HDMI/DP audio stuttering with DP MST on 4.11
Summary: [DP] [BDW] HDMI/DP audio stuttering with DP MST on 4.11
Status: CLOSED FIXED
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:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-08 13:09 UTC by Sebastian Reichel
Modified: 2017-06-30 20:49 UTC (History)
1 user (show)

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


Attachments
dmesg with "debug=0xe" (187.60 KB, text/plain)
2017-06-11 03:48 UTC, Sebastian Reichel
no flags Details

Description Sebastian Reichel 2017-06-08 13:09:12 UTC
Hi,

I have a Thinkpad X250 (i7 from Broadwell generation) on Ultradock (that has a DP MST switch) connected to Yamaha RX-V475. At least once per minute the sound stops shortly for less than a second and then continues normally. This is very annoying and basically renders MST audio support useless, but I did not investigate further so far. The graphical output does _not_ have this problem and continues working normally. The Yamaha av-receiver has a small segment display, which changes it text, but it changes back too fast for me to read. I guess it notices, that the audio stream broke up. I don't see anything useful in dmesg (this is without any special debug flags in kernel parameters).

-- Sebastian
Comment 1 Elizabeth 2017-06-09 19:34:34 UTC
(In reply to Sebastian Reichel from comment #0)
> Hi,
> 
> I have a Thinkpad X250 (i7 from Broadwell generation) on Ultradock (that has
> a DP MST switch) connected to Yamaha RX-V475. At least once per minute the
> sound stops shortly for less than a second and then continues normally. This
> is very annoying and basically renders MST audio support useless, but I did
> not investigate further so far. The graphical output does _not_ have this
> problem and continues working normally. The Yamaha av-receiver has a small
> segment display, which changes it text, but it changes back too fast for me
> to read. I guess it notices, that the audio stream broke up. I don't see
> anything useful in dmesg (this is without any special debug flags in kernel
> parameters).
> 
> -- Sebastian

Hello Sebastian, could you please add the following parameter in the grub: "drm.debug=0xe", and after that get the dmesg and kern.log and attach them. Thanks.
Comment 2 Sebastian Reichel 2017-06-11 03:48:45 UTC
Created attachment 131872 [details]
dmesg with "debug=0xe"

I played music @ 05:35 for ~2 minutes and had some stuttering. There were no corresponding dmesg debug outputs to the audio interruptions.
Comment 3 Elizabeth 2017-06-13 19:29:41 UTC
Thanks for adding the file. Could you tell me if your MST switcher has an additional power source, an AC/DC adapter or power cord for electrical outlet?
This could be affecting the multiplexing process.
Comment 4 Sebastian Reichel 2017-06-13 19:37:15 UTC
The MST Switcher is a Thinkpad Ultradock [0], which supplies power to the notebook. So it has access to a 20V power source. Since it has USB ports, it also has access to 5V.

[0] http://www3.lenovo.com/us/en/accessories/docking/mechanical-docks/ThinkPad-Ultra-Dock-90-W/p/40A20090US
Comment 5 Elizabeth 2017-06-14 19:42:31 UTC
Hello Sebastian,
It seems that most supported features for MST devices were added for kernel 4.12. Could you please change from 4.11 to 4.12 and try to reproduce the issue again:
https://www.kernel.org/
If the issue persist, please get another dmesg and attach it. 
Also, once you provide more information, please change the tag from "NEEDINFO" to "REOPEN". Thank you.
Comment 6 Sebastian Reichel 2017-06-28 19:16:38 UTC
This is not reproducible in 4.12-rc7.
Comment 7 Elizabeth 2017-06-28 20:37:50 UTC
(In reply to Sebastian Reichel from comment #6)
> This is not reproducible in 4.12-rc7.

Hello Sebastian,
Thanks for the answer. I'm changing to CLOSED since it seems to be fixed.


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.