User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36 Build Identifier: Internal speaker does not out any sound after suspend/resume on Z13/Z16 machine after suspend/resume. Reproducible: Always Steps to Reproduce: Steps to Reproduce: 1: Play any Youtube Video (sounds is working) 2: Suspend while it's playing close the lid. (Note: Even if normal suspend and even if video is not playing, issue could be reproduced) 3: Open the lid play any video no sound. Actual Results: No sound output. Expected Results: There should be sound. Kernel: 6.2.8-200.fc37.x86_64/6.2.9-200.fc37.x86_64/6.2.10-200.fc37.x86_64 Version: Fedora 37 BIOS: 1.55 ECFW: 1.56
Moving to pipewire, since that's the default audio system in F37
To investigate if this is a pipewire issue or a kernel-audio related issue (I'll cc jkysela): does the sound reappear if you restart pipewire and wireplumber, `systemctl --user restart pipewire pipewire-pulse wireplumber`?
Also attach output from `alsa-info.sh --no-upload`. Thank you.
Created attachment 1967605 [details] alsa-info.txt request
Created attachment 1971500 [details] dmesg Hello @nielsdegraef I missed your request. The sound does reappear if you restart pipewire and wireplumber, `systemctl --user restart pipewire pipewire-pulse wireplumber`. However after performing this, I tried to suspend/resume the machine in this state but the audio is not working again. I attached the dmesg as well in case this is needed. Please let us know if there are other information you need on our side.
What does pw-top show when you try to play something and it is not working? Are there errors or is there just silence? did you try to change the volume (or mute/unmute)?
Created attachment 1974164 [details] pw-top
Hi Wim See pw-top details. I tried with changing volume, muting, plugging in/out headset (no audio on headset either) and no change - no audio output If I connect with BT headset that has audio, but speakers don't work when BT headset is disconnected. Checking under pulse audio volume control - it is showing output signal, but nothing is actually coming out of the speakers. Thanks Mark
Hi all - anything we can help with here?
It may be a kernel issue. The HDA+CS42L41 driver code receives continuous updates. Could you retest with the latest Fedora 38 kernel ? Also, confirm, that the problem is in driver: systemctl --user stop wireplumber speaker-test -D hw:1 -c 2 -t sine # you should hear a sine sound without pipewire ... do suspend/resume speaker-test -D hw:1 -c 2 -t sine # do you hear the sine sound now?
Hi Jaroslav, Tested this and - can confirm still seeing the issue with latest Fedora (6.4.11-200.fc38.x86_64) - Ran the sine test and had to add a -P 10000 so it would suspend in the middle of the test, but with that was able to reproduce the problem there too. After resume no audio. Interestingly once the test was stopped and restarted then the audio worked again - not sure if that is important or not... Does this mean we should follow up with Cirrus? Mark
Couple more notes/findings. My colleague in Japan tested and noted: Yes after suspend there is sine sound. I also tried to reproduce issue then after system resume I used the command "systemctl --user stop wireplumber" then systemctl --user start wireplumber" and audio is now working. I checked again this morning and on my system: If I play a video in the browser, suspend/resume the sound is lost when restarting the video. If I then close and relaunch the browser the audio is working again. Doesn't that point away from it being a driver issue? Thanks Mark
Hello Jaroslav, Good day. Could we ask for any updates regarding this issue?
Are there any messages in dmesg about audio after resuming?
Created attachment 1992424 [details] dmesg_log Hello @wtaymans Here is dmesg after resume.
PipeWire does snd_pcm_resume() when the status of the device is SND_PCM_STATE_SUSPENDED, it looks like the device is running find in pw-top so all the timers are resumed fine as well. From the bug report, it sounds like an ALSA driver close and reopen might fix it again. I can add that as a workaround but it should not be necessary?
is there any pipewire error log in the journal?
As noted in comment#9, it is probably a kernel driver issue for the Cirrus CS42L41 chip. Those fixes may be related (probably kernel 6.8) - https://lore.kernel.org/alsa-devel/20231026150558.2105827-1-sbinding@opensource.cirrus.com/ . Also, plenty suspend/resume changes for the CS42L41 driver are in kernel 6.6 and more are queued to 6.7. $ git log --format=oneline v6.5..v6.6 sound/pci/hda/cs35l41_hda.c 5d542b850d40cb08a38ad4bb2a944dbf1b7b0683 ALSA: hda: cs35l41: Cleanup and fix double free in firmware request ef4ba63f12b03532378395a8611f2f6e22ece67b ALSA: hda: cs35l41: Support systems with missing _DSD properties cfad53a99d94478480a734602f14d09c5ec1d2da ALSA: hda: cs35l41: Print amp configuration after bind 2d816d4f92086ca0a7b79198794012076b4cab0b ALSA: hda: cs35l41: Ensure amp is only unmuted during playback 7cf5ce66dfda2be444ea668c3d48f732ba4a7fd1 ALSA: hda: cs35l41: Add device_link between HDA and cs35l41_hda c4d0510b81c430249ee69c0554bb7ce4fa3d539e ALSA: hda: cs35l41: Rework System Suspend to ensure correct call separation 01ecc562936439cf6dd08b5f8c6bbed2704d9f9e ALSA: hda: cs35l41: Use pre and post playback hooks a5adbfb60b0299e788189aa8f88d8fa0dafb9d65 ALSA: hda: cs35l41: Move Play and Pause into separate functions f2a58481a5051704390c2d7653b07ab3d97782da ALSA: hda: cs35l41: Ensure we pass up any errors during system suspend. a3ff564658783e3cd9cc3098da4aebd89fe07d74 ALSA: hda: cs35l41: Ensure we correctly re-sync regmap before system suspending. 5299b79ca1a2a9b017b87da08563100b0da98e5b ALSA: hda: cs35l41: Check mailbox status of pause command after firmware load fa3efcc36aacdd8ac9372217970d0ed2eb293fcc ALSA: cs35l41: Use mbox command to enable speaker output for external boost $ git log --format=oneline v6.6.. sound/pci/hda/cs35l41_hda.c dc6e08b1a2ae262c23e14f5c259b4ca63a554e4f ALSA: hda: cs35l41: Fix missing error code in cs35l41_smart_amp() f71e0be5d297b25453fdf4c1757b3e83e94b5f98 ALSA: hda: cs35l41: mark cs35l41_verify_id() static a51d8ba03a4fc92940d5e349f0325f36e85a89cb ALSA: hda: cs35l41: Check CSPL state after loading firmware 33790d1f039114a829433b89fc55a0d781d38d62 ALSA: hda: cs35l41: Do not unload firmware before reset in system suspend 2ee06ff5d7cf5f68bab2bf65a946bb2ffe9982dd ALSA: hda: cs35l41: Force a software reset after hardware reset 881b7bce0c250386680b49b637455d31238a4b30 ALSA: hda: cs35l41: Run boot process during resume callbacks fff393db71c1d53a13f9eb2f8da77c1f5e4e30bc ALSA: hda: cs35l41: Assert Reset prior to de-asserting in probe and system resume a7423e9019a9a595919da44104725eef8a518652 ALSA: hda: cs35l41: Assert reset before system suspend 39cd06e3f7b75b629f2987aa51ab26fb820d167b Merge tag 'asoc-v6.7' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next 87543ce5030a17ff5056668d7e6c433168c63bb5 Merge branch 'for-linus' into for-next 4c870513fbb02b842408b840cf68ea8fe09ed82e ALSA: hda: cs35l41: Add read-only ALSA control for forced mute 447106e92a0c86c332d40710436f38f64c322cd6 ALSA: hda: cs35l41: Support mute notifications for CS35L41 HDA 206b250c3e9be44c096bb9bb1f9d6b7f3440bfbb ALSA: hda: cs35l41: Consistently use dev_err_probe() 85a1bf86fac0c195929768b4e92c78cad107523b ALSA: hda: cs35l41: Undo runtime PM changes at driver exit time 486465508f8a5fe441939a7d97607f4460a60891 ALSA: hda: cs35l41: Fix unbalanced pm_runtime_get() 77bf613f0bf08c021309cdb5f84b5f630b829261 ASoC: cs35l41: Fix broken shared boost activation I reassigned this issue to me. If you like to test the very latest upstream kernels (from git), check https://bodhi.fedoraproject.org/updates/?packages=kernel .
ah cool - will see if we can retest with those. Thanks! Mark
This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '37'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 37 entered end-of-life (EOL) status on 2023-12-05. Fedora Linux 37 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.