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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
