Rockbox mail archive
Subject: [third try] buffering crashes on low mem targets[third try] buffering crashes on low mem targets
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Mike Giacomelli <giac2000_at_hotmail.com>
Date: Sun, 13 Sep 2009 22:46:50 -0700
JdGordon and I dug into this tonight.
Heres what we have found so far: My e200v1, Fuze, and Clipv1 all deadlock in the same way if the compressed audio buffer is small enough (<500kb or so). The sim also deadlocks if the buffer is small enough (~100KB was small enough for me) but it takes much longer and deadlocks nearly always happen on track change, not during play.
So basically playback/buffering do not handle small buffers very well and its not a hardware/driver specific issue. On the sim, deadlocks are always preceded by playback's audio_finish_load_track function trying calling buffering.c's bufopen function. If the track change is going to be successful, bufopen will find a new buffer and allocate it. If its going to deadlock, it'll not find a buffer, audio_finish_load_track will return early (presumably leaving things in a bad state), playback will continue for a little while and then eventually deadlock. The deadlock itself is usually in one of the callbacks, but I think thats just a result of those being left on the playback event queue with nothing else happening to service them. Interestingly, bufopen will very regularly fail elsewhere (at least 1 time per second) but this seems to be ok to the code as long as its not during a track change.
Additionally lots of other stuff is going on that probably shouldn't. For example, the buffering code endlessly tries to read the metadata for the next track even though its actually trying to buffer the next segment of the current track (and probably no where near the end of the current track even). This seems like a waste a best and at worst could be contributing to instability.
Deadlocks on targets seem a bit different, since I've seen them on track changes but also in the middle of the current track. They also seem to happen much quicker (in one case I observed the sim play for more then an hour with a buffer small enough to crash the e200v1 in seconds).
Thats all I have for now. I think I need someone familiar with buffering/playback to tell me if this means anything at all.
Mike
_________________________________________________________________
Hotmail: Free, trusted and rich email service.
http://clk.atdmt.com/GBL/go/171222984/direct/01/
Received on 2009-09-14
Date: Sun, 13 Sep 2009 22:46:50 -0700
JdGordon and I dug into this tonight.
Heres what we have found so far: My e200v1, Fuze, and Clipv1 all deadlock in the same way if the compressed audio buffer is small enough (<500kb or so). The sim also deadlocks if the buffer is small enough (~100KB was small enough for me) but it takes much longer and deadlocks nearly always happen on track change, not during play.
So basically playback/buffering do not handle small buffers very well and its not a hardware/driver specific issue. On the sim, deadlocks are always preceded by playback's audio_finish_load_track function trying calling buffering.c's bufopen function. If the track change is going to be successful, bufopen will find a new buffer and allocate it. If its going to deadlock, it'll not find a buffer, audio_finish_load_track will return early (presumably leaving things in a bad state), playback will continue for a little while and then eventually deadlock. The deadlock itself is usually in one of the callbacks, but I think thats just a result of those being left on the playback event queue with nothing else happening to service them. Interestingly, bufopen will very regularly fail elsewhere (at least 1 time per second) but this seems to be ok to the code as long as its not during a track change.
Additionally lots of other stuff is going on that probably shouldn't. For example, the buffering code endlessly tries to read the metadata for the next track even though its actually trying to buffer the next segment of the current track (and probably no where near the end of the current track even). This seems like a waste a best and at worst could be contributing to instability.
Deadlocks on targets seem a bit different, since I've seen them on track changes but also in the middle of the current track. They also seem to happen much quicker (in one case I observed the sim play for more then an hour with a buffer small enough to crash the e200v1 in seconds).
Thats all I have for now. I think I need someone familiar with buffering/playback to tell me if this means anything at all.
Mike
_________________________________________________________________
Hotmail: Free, trusted and rich email service.
http://clk.atdmt.com/GBL/go/171222984/direct/01/
Received on 2009-09-14
Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy