Closed ali1234 closed 7 years ago
you are controlling a set of APA102 by passing data and clock continuously... if you interrupt playback arbitrarily then yes, they may remain in their state. I don't think there is any workaround but we'll try a few things.
Backtrace on the hung process:
(gdb) bt
#0 0xb6cb8b80 in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0xb635d428 in poll (__timeout=-1, __nfds=1, __fds=0xbea37530)
at /usr/include/arm-linux-gnueabihf/bits/poll2.h:46
#2 snd1_pcm_wait_nocheck (pcm=pcm@entry=0xb590fe68, timeout=timeout@entry=-1) at pcm.c:2418
#3 0xb63971d8 in snd_pcm_dmix_drain (pcm=0xb590fe68) at pcm_dmix.c:649
#4 0xb63f44a4 in ao_plugin_close () from /usr/lib/ao/plugins-4/libalsa.so
#5 0xb6ed7d14 in ao_close () from /usr/lib/libao.so.4
Cannot access memory at address 0x40240000
#6 0x00013290 in ?? ()
Cannot access memory at address 0x40240000
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
The hang happens even if libpivumeter is not installed.
The same hang occurs with sox:
(gdb) bt
#0 0xb6ddcb80 in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0xb6bac428 in poll (__timeout=-1, __nfds=1, __fds=0xbe88c4e8)
at /usr/include/arm-linux-gnueabihf/bits/poll2.h:46
#2 snd1_pcm_wait_nocheck (pcm=pcm@entry=0xeff2b0, timeout=timeout@entry=-1) at pcm.c:2418
#3 0xb6be61d8 in snd_pcm_dmix_drain (pcm=0xeff2b0) at pcm_dmix.c:649
#4 0xb6c4092c in ?? () from /usr/lib/arm-linux-gnueabihf/sox/libsox_fmt_alsa.so
This appears to be a bug in the alsa meter PCM slave. I can't reproduce the hang after removing it from asound.conf.
I have reported this upstream: http://mailman.alsa-project.org/pipermail/alsa-devel/2017-March/118459.html
I'll close this as this seems not to be related to pivumeter.
To reproduce, play an ogg file with ogg123 while having the vumeter enabled. Press ctrl-c to stop playing. About 50% of the time this result in ogg123 hanging. The VU meter remains lit when this happens.