alsa-project/alsa-lib issue #321 was opened from nachopitt:

Hello,

I'm using alsa-lib to add sound playback functionality to a Embedded Linux system.

Recently I noticed that whenever I mount a UBI partition while there is a sound file being played back with the help of the aplay command, the aplay process hangs forever and the sound playback stops immediately.

``` # aplay -D output1 1.wav & Playing WAVE '1.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono # # # mount -t ubifs /dev/ubi0_5 /opt/conf/Logging UBIFS (ubi0:5): background thread "ubifs_bgt0_5" started, PID 190 UBIFS (ubi0:5): UBIFS: mounted UBI device 0, volume 5, name "Logging" UBIFS (ubi0:5): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes UBIFS (ubi0:5): FS size: 1650688 bytes (1 MiB, 13 LEBs), journal size 1142785 bytes (1 MiB, 8 LEBs) underrun!!! (at least 0.044 ms loUBIFS (ubi0:5): reserved for root: 0 bytes (0 KiB) ng) UBIFS (ubi0:5): media format: w4/r0 (latest is w5/r0), UUID 26A3D522-A34F-4FE4-BF6C-931A9FE59854, small LPT model # ```

I also prepared a small video that captures the exact moment where the issue is reproduced in case you want it to see it in action:

https://www.youtube.com/watch?v=M9bW2k2CTVs

The only way to recover from this scenario is to kill the stuck aplay process manually and execute it again.

Last time I tried to debug this, I attached the gdbserver to the still stuck aplay process and backtrace showed the following information:

``` (gdb) bt arm-linux-gnueabihf-gdb bin/aplay (wd: ~/home_volume/git_repos/alsa/alsa-install/usr) (gdb) bt #0 0x76d96ba4 in ?? () **#1 0x76f0e222 in snd1_pcm_wait_nocheck (pcm=0x879280, timeout=-1) at pcm.c:2898** Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) frame 1 #1 0x76f0e222 in snd1_pcm_wait_nocheck (pcm=0x879280, timeout=-1) at pcm.c:2898 2898 err_poll = poll(pfd, npfds, timeout); (gdb) ```

It is clear to me that the `poll` function is waiting for something to change in the file descriptors and it waits infinitely due to the `timeout = -1` argument, but none of the file descriptors in `pfd` ever change or become ready after the mount command is executed during the sound playback.

I'm currently using both alsa-lib and alsa-utils v1.2.6. The SoC is an NXP i.MX6 Solo which includes an Armv7-A 32bits Cortex-A9 Core CPU Platform. Linux Kernel BSP is based on 4.14.98.

Most likely this is an issue with my system configuration, but since you guys are more familiar with alsa than anyone on the planet, I thought you might have some ideas to troubleshoot and debug this because I currently do not have any clue.

Do you know what could cause this behavior? Is there any possibility that there is an issue in alsa-lib? Do you have any suggestions to debug and troubleshoot the error to get more information?

Any help will be really appreciated.

Thanks a lot. Best regards.

Issue URL : https://github.com/alsa-project/alsa-lib/issues/321 Repository URL: https://github.com/alsa-project/alsa-lib