We just submitted the final build of Beampunk to be shipped next week () in Catalog. Naturally, as soon as we did that, we were kicking around that build some more and ran into a watchdog timer failure we’ve never seen before:
Run loop stalled for more than 10 seconds pc=0x24089ECE lr=0x24089EF9
(That’s from errorlog.txt – doesn’t seem to be anything in crashlog.txt?) This was mid-gameplay when a bunch of action was happening, but nothing terribly unusual. This was on a device running SDK 3.0.5 and built against the 3.0.5 SDK. My understanding is those symbols are in the SDK-supplied but user-space code running in the game task? (As opposed to the audio task which happened to be running?) Translating them using the 3.0.5 symbols (from the linux SDK because of this thread) we get:
> pd-addr2line --symbols PlaydateSDK-3.0.5/bin/symbols.db --exe pdex.elf 0x24089ECE 0x24089EF9
0x24089ece:
at /Core/audio/adpcm.c:109 [hw:604544660]
at /Core/audio/adpcm.c:131 [hw:1]
0x24089ef9:
at /Core/audio/adpcm.c:109 [hw:604544660]
at /Core/audio/adpcm.c:138 [hw:1]
at /Core/audio/adpcm.c:140 [hw:1]
We recently changed all our sfx over from Linear PCM at 44kHz to ADPCM at 22kHz. Wondering if we’re now exercising some path with some limitation we’re not aware of? (We’re not super careful about, say, the number of samples we trigger in one frame.) Of course this could be us playing sounds in a loop or something but I don’t see anything obvious like this.
Any suggestions what this might be?
Thanks,
Jesse
(For posterity for ourselves, this was BP build 1.0-12-d95d82c4 as shown in the options screen.)
I combed through the ADPCM decoder, where those addresses point to, and don't see any obvious way it could get stuck in a loop. To test if there's some edge case I'm missing I downloaded the build that y'all uploaded earlier today and wrote a test that plays all of the audio files in sequence using a sampleplayer, ran without getting stuck. Tried with a fileplayer instead, same thing. Are you ever changing the playback rate or using a rate modulator? Are you looping with a range set? I'm trying to think of anything else to try..
I think it may be possible, too, that the hang is actually on the game task but the audio task is running when the watchdog timer fires. But in that case I don't see how switching from uncompressed audio to ADPCM would make a difference. If you want to DM me a build and give repro steps I'm happy to see if I can catch this in the debugger.
Thanks Dave! Appreciate the fast response and deep investigation, as always. We do change the rate for some sounds but nothing that was happening at the time of the issue & we don’t loop with a range set.
Quite possible the switch from uncompressed to ADPCM was totally unrelated, especially if this crash position might be unrelated to the actual game code taking up the time.
We’ve only seen this happen once and have not been able to reproduce yet. We’ll see if we can get something consistent and reach out with a build if so. Thanks again!
I suspect these are probably the same root cause? We switched to ADPCM about the same time we started using setSample() much more so probably the former was just a red herring.
) in Catalog. Naturally, as soon as we did that, we were kicking around that build some more and ran into a watchdog timer failure we’ve never seen before:
Are you ever changing the playback rate or using a rate modulator? Are you looping with a range set? I'm trying to think of anything else to try..