Bad PCM stream after a suspend/resume cycle

Mirza Krak mirza.krak at gmail.com
Thu Jan 11 01:06:12 PST 2018


Hi.

I have a quite simple problem really (simple test-case at least).

Following describes the test case:

$ aplay test.wav

# While the .wav is playing suspend the system
$ systemctl suspend

# When system is resumed I get the following error on my aplay command
aplay: pcm_write:2030: write error: File descriptor in bad state

I was expecting for the playback to resume.

I did some debugging using "aplay" and what I can see that happens
before the EBADFD error is that the "writei_func()" returns a positive
value once which results in a call to "snd_pcm_wait()" and on the next
"writei_func()" call -EBADFD is returned.

I would expect a -ESTRPIPE error which should then result in that the
PCM stream to be "resumed" (according to documentation at least). I
have tried "forcing" a call to "suspend()" on the first write error in
aplay after system is resumed and it actually works, kinda. The
playback is resumed even-though the "snd_pcm_resume()" call returns an
error.

I have not worked much with the sound subsystem before and I am having
a hard time following all the call paths to see who/what is to blame
for this behavior. Maybe it expected to work like this? And I do not
know if this is only on my SoC or if this is a generic sound problem.

Information about my system:

Using a RK3288 SoC (RK3288-FireFly board) with 4.14.13 Linux kernel
(latest stable).

alsa-lib version 1.1.4.1

Playback using I2S

$ cat /proc/asound/cards
 0 [I2S            ]: I2S - I2S
                      I2S
$ cat /proc/asound/card0/pcm0p/info
card: 0
device: 0
subdevice: 0
stream: PLAYBACK
id: Audio es8328-hifi-analog-0
name:
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 1

Let me know if there is additional information that I need to provide.

-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak



More information about the Linux-rockchip mailing list