Bugzilla – Bug 1219545
sound hangs after zypper update; unable to play any sound
Last modified: 2024-06-17 20:15:00 UTC
Sound used to work fine until yesterday Feb 3 zypper update. Today after boot the sound configuration was non-existent. After yast2 sound Quick configuration the test sound produces no output. Set all volume controls to max. No improvement. Reboot doesn't help. Repeatedly deleting and recreating the sound configuration with yast2 in various ways doesn't help. When an application like aplay, audacious tries to play a sound it hangs. yast2 sound configuration info. 100 Series/C230 Series Chipset Family HD Audio Controller Configured as sound card number 0 Driver snd-hda-intel PulseAudio is enabled. aplay just hangs until it timeouts: $ ll /usr/share/sounds/purple/alert.wav -rw-r--r-- 1 root root 23314 May 9 2022 /usr/share/sounds/purple/alert.wav $ aplay /usr/share/sounds/purple/alert.wav Playing WAVE '/usr/share/sounds/purple/alert.wav' : Signed 16 bit Little Endian, Rate 22050 Hz, Mono ALSA lib pcm_pulse.c:758:(pulse_prepare) PulseAudio: Unable to create stream: Timeout aplay: set_params:1416: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 16 CHANNELS: 1 RATE: 22050 PERIOD_TIME: 125000 PERIOD_SIZE: (2756 2757) PERIOD_BYTES: (5512 5513) PERIODS: 4 BUFFER_TIME: 500000 BUFFER_SIZE: 11025 BUFFER_BYTES: 22050 TICK_TIME: [0 0]
Could you try to boot with the previous kernel to see whether it works or not? If it works with the previous kernel, run alsa-info.sh as root with --no-upload option, and attach the output to Bugzilla (don't paste). Then boot the latest kernel and verify it's still broken, and give the alsa-info.sh output from there as well.
I tried again to get sound working with yast2 and this time it works. Maybe because PulseAudio is now not enabled? Maybe Suse can make sure not to remove an existing sound configuration when it updates the kernel? Because it is disurbing having to debug something like that. Took a lot of time for no reason.
Please don't use YaST sound module. That may make things rather confusing. It was already dropped from TW, but it's still left for Leap just to be conservative. And, kernel will never drop any sound configuration. If it happened, it must be something else.
It may be easy for you to say "don't use this", but then it is unclear how to get sound working. Why not post a message in "yast2 sound" explaining to ignore it and how one should configure sound instead?
In general, if the sound doesn't work without involvement of YaST2 sound, it's a thing to be fixed, and better to be left without modifying environment without YaST sound. YaST sound puts the extra config that may interfere the normal operation. It might work, or it might break things. It's merely a cargo workaround. It's still present on Leap 15.x, as already mentioned, just for being conservative. I already suggested to drop or put a warning, but it wasn't done for Leap, so far.
Then this bug is a notification that your intended automatic sound configuration does not work as it should and a request to improve it such that it always works without manual intervention with the yast2 sound module. As it currently stands, it clearly doesn't.
Then let's start from a clear state. Please drop the modprobe.d config YaST2 sound created, and reboot. When the problem doesn't happen and the sound works, get alsa-info.sh output; run the script with --no-upload option and attach the output file (don't paste) to Bugzilla. And, when the problem happens, get alsa-info.sh output again. Upload the output. In that way, we can compare the low-level sound device states. Also, please show your sound setup. Give the package list (the output "rpm -qa | sort"), the contents of /etc/sysconfig/sound. Last but not least, what does show ls /etc/alsa/conf.d/ ??
No response, as per bug 1226442 user moved on to 15.6