FS#47446 - [alsa-lib] alsa 1.1.0 no sound and 100% cpu on resume if sound playing on suspend
Attached to Project:
Arch Linux
Opened by Eric Le Lay (elelay) - Saturday, 19 December 2015, 16:57 GMT
Last edited by Evangelos Foutras (foutrelis) - Thursday, 25 January 2018, 12:30 GMT
Opened by Eric Le Lay (elelay) - Saturday, 19 December 2015, 16:57 GMT
Last edited by Evangelos Foutras (foutrelis) - Thursday, 25 January 2018, 12:30 GMT
|
Details
Description:
When my laptop suspends with sound playing (mp3 in vlc or video in firefox), playback doesn't recover on resume and the application is frozen consuming 100% CPU. It used to resume without error a few weeks before (end of November at most). Downgrading linux to 4.2.3 didn't help. When I reinstall alsa-lib-1.0.29-1-x86_64, alsa-plugins-1.0.29-2, alsa-utils-1.0.29-2 the problem goes away. This is almost certainly an upstream bug. Their bugtracker is down so in the meantime I enter the information here. Additional info: * linux-4.2.5-1, all packages at their latest (2015-12-19) * standard alsa config : no pulseaudio * Lenovo X220 Steps to reproduce: $ vlc /path/to/audio_file (keep it playing) (suspend to ram) (wake-up) (in another terminal) htop shows vlc hogging a core. (you now have to kill vlc and start it again) Here is a stacktrace in gdb gdb vlc r -I dummy /path/to/audio_file (suspend to ram) (wake-up) (in another terminal) htop shows vlc hogging a core. (in gdb) Ctrl-C (gdb) info threads Id Target Id Frame 9 Thread 0x7fffdffff700 (LWP 1874) "vlc" 0x00007ffff74df957 in semop () from /usr/lib/libc.so.6 6 Thread 0x7fffec110700 (LWP 1871) "vlc" 0x00007ffff79accfc in __lll_lock_wait () from /usr/lib/libpthread.so.0 2 Thread 0x7ffff1953700 (LWP 1867) "vlc" 0x00007ffff79aa07f in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 * 1 Thread 0x7ffff7f2b7c0 (LWP 1866) "vlc" 0x00007ffff79a570d in pthread_join () from /usr/lib/libpthread.so.0 (gdb) thread 9 [Switching to thread 9 (Thread 0x7fffdffff700 (LWP 1874))] #0 0x00007ffff74df957 in semop () from /usr/lib/libc.so.6 (gdb) bt #0 0x00007ffff74df957 in semop () from /usr/lib/libc.so.6 #1 0x00007ffff458a817 in ?? () from /usr/lib/libasound.so.2 #2 0x00007ffff45553d6 in snd_pcm_recover () from /usr/lib/libasound.so.2 #3 0x00007ffff480395f in ?? () from /usr/lib/vlc/plugins/audio_output/libalsa_plugin.so #4 0x00007ffff716d4c5 in ?? () from /usr/lib/libvlccore.so.8 #5 0x00007ffff71302f6 in ?? () from /usr/lib/libvlccore.so.8 #6 0x00007ffff7131f9d in ?? () from /usr/lib/libvlccore.so.8 #7 0x00007ffff79a44a4 in start_thread () from /usr/lib/libpthread.so.0 #8 0x00007ffff74de13d in clone () from /usr/lib/libc.so.6 |
This task depends upon
Closed by Evangelos Foutras (foutrelis)
Thursday, 25 January 2018, 12:30 GMT
Reason for closing: Won't fix
Additional comments about closing: Old bug; OP moved to PulseAudio.
Thursday, 25 January 2018, 12:30 GMT
Reason for closing: Won't fix
Additional comments about closing: Old bug; OP moved to PulseAudio.
I have an x220 as well and do not experience this problem on the current Linux kernel and up to date packages. Can you please let me know if this is still an issue for you. Thank you.
This is from http://www.alsa-project.org/main/index.php/Detailed_changes_v1.0.29_v1.1.0
PCM: snd_pcm_xxxx_drain() maybe blocked after suspend and resume
After suspend and resume, the alsa driver is stopped. But if alsa-lib run
into snd_pcm_xxxx_drain(), it need to wait avail >= pcm->stop_threshold,
otherwise, it will not exit the loop, so finally it is blocked at poll() of
snd_pcm_wait_nocheck(pcm, -1).
This patch is to add state check after snd_pcm_wait_nocheck(pcm, -1), if
the state is SND_PCM_STATE_SUSPENDED, then return error.
Their change log for between 1.1.0 and 1.1.1 doesn't mention any suspend or resume changes, so this bug may still exist since we are on 1.1.1
Looks like ALSA doesn't have a bug tracker anymore and suggests you subscribe and submit bugs to their mailing list, details here:
http://alsa-project.org/main/index.php/Bug_Tracking