[regression] [bisected] display audio usually doesn't work
Steps to reproduce:
Boot with the display plugged in, then play audio. It doesn't work probably around 90% of the time. I can do a bunch of boots and figure out a more specific statistic if that would be helpful. When I unplug and replug the monitor, it does work.
I've bisected the changes and c3c5dc1d9224fb3e0c6a104527567090fbbae13c is the first bad commit, and more specifically it seems like removing the intel_crtc_wait_for_next_vblank calls in the codec_disable function (the hsw variants are the ones that my system uses, I believe), although I'm sure that's not the proper fix.
Definitely let me know if there is any other information that would be useful, or if there are any patches that you would like me to try.
uname -m: x86_64
uname -r : 6.6.0-rc1-00374-gdc4cd6e4e53d (drm-tip as of writing)
Distribution: Arch Linux
Machine: XPS 15 9510
Display connector: DisplayPort over Dell WD19 dock OR HDMI via type-c to HDMI cable
Display: LG 32UK550/UL550
Attached dmesg includes me
- booting, playing some audio (and it doesn't work)
- unplugging the DP cable
- re-plugging the DP cable
- playing some audio (and it does work)
Activity
added Community label
Cc : @vsyrjala
added regression label
added platform: TGL label
Very strange that removing the vblank waits from codec_disable would help.
Does this reordering make any difference?
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c @@ -561,9 +561,9 @@ static void intel_mst_disable_dp(struct intel_atomic_state *state, intel_hdcp_disable(intel_mst->connector); - drm_dp_remove_payload_part1(&intel_dp->mst_mgr, new_mst_state, new_payload); - intel_audio_codec_disable(encoder, old_crtc_state, old_conn_state); + + drm_dp_remove_payload_part1(&intel_dp->mst_mgr, new_mst_state, new_payload); } static void intel_mst_post_disable_dp(struct intel_atomic_state *state,The log also shows some really odd behaviour. We start by driving the MST display with pipe B (and presumably that is when the audio doesn't work), but later userspace suddenly decides to switch to pipe D for whatever reason (and I guess at that point audio starts working).
What kind of userspace are you running that does this weird stuff? Can you try with a a simpler setup that wouldn't do this funny pipe switching (eg. no GUI stuff at all)?
Did you try all the audio pcm devices when audio didn't work? Not really sure how the MST stream<->pcm device association works now (it no longer seems to make any sense even with DP SST/HDMI these days).
added feature: display/audio label
added feature: display/DP MST label
That reordering doesn't seem to make any effect.
The output of
aplay -Lisnull Discard all samples (playback) or generate zero samples (capture) lavrate Rate Converter Plugin Using Libav/FFmpeg Library samplerate Rate Converter Plugin Using Samplerate Library speexrate Rate Converter Plugin Using Speex Resampler jack JACK Audio Connection Kit oss Open Sound System pipewire PipeWire Sound Server pulse PulseAudio Sound Server speex Plugin using Speex DSP (resample, agc, denoise, echo, dereverb) upmix Plugin for channel upmix (4,6,8) vdownmix Plugin for channel downmix (stereo) with a simple spacialization default Default ALSA Output (currently PipeWire Media Server) sysdefault:CARD=PCH HDA Intel PCH, ALC289 Analog Default Audio Device front:CARD=PCH,DEV=0 HDA Intel PCH, ALC289 Analog Front output / input surround21:CARD=PCH,DEV=0 HDA Intel PCH, ALC289 Analog 2.1 Surround output to Front and Subwoofer speakers surround40:CARD=PCH,DEV=0 HDA Intel PCH, ALC289 Analog 4.0 Surround output to Front and Rear speakers surround41:CARD=PCH,DEV=0 HDA Intel PCH, ALC289 Analog 4.1 Surround output to Front, Rear and Subwoofer speakers surround50:CARD=PCH,DEV=0 HDA Intel PCH, ALC289 Analog 5.0 Surround output to Front, Center and Rear speakers surround51:CARD=PCH,DEV=0 HDA Intel PCH, ALC289 Analog 5.1 Surround output to Front, Center, Rear and Subwoofer speakers surround71:CARD=PCH,DEV=0 HDA Intel PCH, ALC289 Analog 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers hdmi:CARD=PCH,DEV=0 HDA Intel PCH, LG HDR 4K HDMI Audio Output hdmi:CARD=PCH,DEV=1 HDA Intel PCH, HDMI 1 HDMI Audio Output hdmi:CARD=PCH,DEV=2 HDA Intel PCH, HDMI 2 HDMI Audio Output hdmi:CARD=PCH,DEV=3 HDA Intel PCH, HDMI 3 HDMI Audio Output usbstream:CARD=PCH HDA Intel PCH USB Stream Output sysdefault:CARD=Dock WD19 Dock, USB Audio Default Audio Device front:CARD=Dock,DEV=0 WD19 Dock, USB Audio Front output / input surround21:CARD=Dock,DEV=0 WD19 Dock, USB Audio 2.1 Surround output to Front and Subwoofer speakers surround40:CARD=Dock,DEV=0 WD19 Dock, USB Audio 4.0 Surround output to Front and Rear speakers surround41:CARD=Dock,DEV=0 WD19 Dock, USB Audio 4.1 Surround output to Front, Rear and Subwoofer speakers surround50:CARD=Dock,DEV=0 WD19 Dock, USB Audio 5.0 Surround output to Front, Center and Rear speakers surround51:CARD=Dock,DEV=0 WD19 Dock, USB Audio 5.1 Surround output to Front, Center, Rear and Subwoofer speakers surround71:CARD=Dock,DEV=0 WD19 Dock, USB Audio 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers iec958:CARD=Dock,DEV=0 WD19 Dock, USB Audio IEC958 (S/PDIF) Digital Audio Output iec958:CARD=Dock,DEV=1 WD19 Dock, USB Audio #1 IEC958 (S/PDIF) Digital Audio Output usbstream:CARD=Dock WD19 Dock USB Stream Output usbstream:CARD=JV601 JOUNIVO JV601 USB Stream Output usbstream:CARD=Camera HD Web Camera USB Stream OutputWhen the audio is working normaly,
speaker-test -D hdmi:CARD=PCH,DEV=0 -c 2works properly to generate noise. It doesn't work properly when the audio is broken (I do need to wait a few seconds after playing via mpv to wait for pipewire to not be holding the device anymore though).DEV={1,2,3}also don't play anything.Userspace wise, I'm playing a audio stream through mpv with pipewire. I think the bug is somehow related to modechanges (or something else that starting a graphical session does). If I run mpv from a TTY on boot, it always seems to work. But if I run it in
cageit doesn't work most of the time. It seems even when it does work, if I restart cage it (usually) doesn't work. So seems like there's like a chance of it breaking on every modeset or something?It also repro's if I never start pipewire in the first place and just use speaker-test (but only after starting a GUI)
Considering speaker-test doesn't work when things are broken, it does seem like a kernel bug and not a userspace one?
I'm happy to provide some more logs of certain situations if that would be helpful. Thanks!
Edited by Russell GreeneAttached some logs.
2vblank-notworking*.txtare from drm-tip as of a a few days ago, and1vblank-working*.txtare from that same kernel with one of theintel_crtc_wait_for_next_vblankinhsw_audio_codec_disablecommented out.NOTE: I stripped timestamps out for diffing...I can get new ones with those back in (forgot to back them up) if that's important.
Edited by Russell GreeneHere are also a couple of branches that might be interesting to try out:
https://github.com/vsyrjala/linux.git mst_sequence_fixes https://github.com/vsyrjala/linux.git audio_fastset_2The first one fixes some ordering issues in the modeset sequence, the second attempts to remove the need for a full modeset for audio changes.
The mst_sequence_fixes branch works roughly half the time (6/12 boots). From that branch, not working
amixer contents:numid=4,iface=MIXER,name='Master Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=3,iface=MIXER,name='Master Playback Volume' ; type=INTEGER,access=rw------,values=2,min=0,max=65536,step=1 : values=55053,55053 numid=2,iface=MIXER,name='Capture Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=1,iface=MIXER,name='Capture Volume' ; type=INTEGER,access=rw------,values=2,min=0,max=65536,step=1 : values=61680,61680and not working (it's the same):
numid=4,iface=MIXER,name='Master Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=3,iface=MIXER,name='Master Playback Volume' ; type=INTEGER,access=rw------,values=2,min=0,max=65536,step=1 : values=55053,55053 numid=2,iface=MIXER,name='Capture Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=1,iface=MIXER,name='Capture Volume' ; type=INTEGER,access=rw------,values=2,min=0,max=65536,step=1 : values=61680,61680these were both from the
mst_sequence_fixesbranch.The
audio_fastset_2branch works every time (out of 6 boots)!Edited by Russell GreeneYep, you're totally correct, passing
-c 0seems to get a working output. I have logs from 2 boots here, both from drm-tip as of today. The first one audio worked after the modeset, the second one audio didn't work after the modeset. I haveamixer contentsfor both before and after the modeset, and dmesg logs as well.Did a bunch more boots as I realized those amixer contents aren't that consistent.
Should be fixed by
commit 07e823c0fd991565106eff6f03892c5d645cd690 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Tue Nov 21 07:43:24 2023 +0200 drm/i915: Implement audio fastsetUnfortunately I don't have any good plan for stable since that patch series is rather large to comfortably backport. But I'll ponder on it a bit more perhaps.
Thanks for the bug report and testing.
@russelltg are you able to test latest drm-tip again if issue better/fixed?
Tested 3 kernels today:
6.10.8, 6.6.49, and drm-tip @ f87cdc7bf4ab80cce53a4d300611f2d4ccc8cb86 (I can update again if you think it's changed, cgit.freedesktop is just down rn so was latest I had access to) and they all seem to have the same behavior: HDMI audio usually works when I boot to a tty, then I start my display manager which causes a modeset, then HDMI audio usually doesn't work.
Sometimes it never works, sometimes it always works tho.
I will note that my test setup has changed slighty, I now use a HDMI cable instead of a DP cable (I think the DP input on my monitor died), but the symptoms seem the same.
Cc : @vsyrjala
