Date 13.6.2014 08:52, Sergey wrote:
These patches originate from `aplay -vvv /dev/zero` not responding to Ctrl+C when playing to plugged "null", e.g. pcm.!default { type plug slave.pcm { type null } slave.format S32_LE }
First patch fixes snd_pcm_write_areas() stuck in a loop because of transfer func() always returning 0. That caused application calling it to freeze. In the example above it have frozen aplay. If it was called by firefox, it would freeze firefox.
Is it a good way to fix it? Should snd_pcm_read_areas() be fixed like that too?
Nope: The whole culprit was in the null plugin - the stream was not started, thus new samples were not delivered.
I tried to fix this in:
http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=9c3086fb749cd5545be3f...
Second patch fixes aplay itself, not returning from pcm_write() after SIGINT.
Thanks, looks good, but I added the in_aborting check to other functions, too:
http://git.alsa-project.org/?p=alsa-utils.git;a=commit;h=c06dbf077459923066c...
Additionally aplay may restore original interrupt handler, to make second Ctrl+C stop it for sure. In case of other bugs in alsa-lib or third-party slave pcms it seems better than SIGkilling it manually.
Comments and suggestions are welcome.
Regardless of these patches' fate null plugin must be fixed on its own.
Patches (2): pcm: break out of snd_pcm_write_areas() if write function returned 0 aplay: Escape from pcm_write() when in_aborting state
src/pcm/pcm.c | 2 +- aplay/aplay.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)