Triode wrote:
> I'm not sure the error message will impact this as there is something to
> recover from it straight afterwards (you only see if as we capture alsa
> log) - I will look into though.
>
> What is interesting is that if you stop and then restart the device it
> works again in the problem case, but a sleep after closing doesn't do
> the same thing (as logically this is doing the same thing...)
I have been single stepping the output_alsa code under gdb, and trying
to figure out what it happening. The only thing I could find out (which
you presumably already know) is which statement is causing
SNDRV_PCM_IOCTL_START errors. I see what you mean by something to
recover it straight afterwards.
Code:
--------------------
if (start && alsa.mmap) {
if ((err = snd_pcm_start(pcmp)) < 0) {
if ((err = snd_pcm_recover(pcmp, err, 1)) < 0)
--------------------
So snd_pcm_recover() is immediately called with the error code (-32)
from the failed call to snd_pcm_start(), which keeps the music playing.
The mystery as to why I can't emulate the effect of stopping the player
and restarting it using calls to sleep() is still bugging me. I have
tried putting calls to sleep() in various places to no avail, and yet
every single time I stop and restart the player after it goes into
demented gerbil mode on a 32kHz track, it recovers cleanly and plays
fine. I think I've taken this as far as my limited debugging skills
will let me. Unless you have any further suggestions, I will stand down
for now.
----------------------
"Dreamer, easy in the chair that really fits you..."
------------------------------------------------------------------------
dsdreamer's Profile: http://forums.slimdevices.com/member.php?userid=12588
View this thread: http://forums.slimdevices.com/showthread.php?t=99395
_______________________________________________
unix mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/unix
