Sampleplayer stops playing randomly

SDK Bug Reports
1

Looping sampleplayer randomly stops playing. Player stops and setLoopCallback() stops being called but isPlaying() still returns true and both getVolume() / getRate() return correct values.

Not sure if the trigger is too many setRate() calls, a specific rate value, specific audio file or something completely else. I created a minimal example (the sound is unpleasant, but it’s the original):

sp.zip (88.5 KB)

To reproduce: Run this on simulator (I use Mac/M1) or real playdate HW and wait a bit. It breaks randomly — sometimes in just a few seconds, sometimes after a bit (if it doesn’t break in about 30s I get antsy and restart the game in simulator, but when testing in-game, it sometimes stopped even after many minutes). Rate + volume and isPlaying are on display, loopCallback prints into console.

It behaves just like buffer underrun in fileplayer (the rest of the game continues to run just fine) but I’m not sure how that could apply to sampleplayer that has it all loaded in ram. Also, the minimal example above seems to indicate that it’s not a cpu/ram issue.

After trying out many things over last week, I found that reducing number of callbacks, rounding the rate to 1 decimal, or setting restricted playRange might have fixed the issue — but as I don’t know the cause, maybe it’s now just less frequent. (Now I even get that setting rate on every update is needless/bad practice ;-))

:playdate_heart: Also, thanks for a great SDK – for me it’s one of the most frictionless experiences with a new env! :sparkles:

1 Like
2

Ha, what timing! I just encountered this bug and was working on a minimal reproduction. I'll toss it up here just in case having more samples helps.

I used an audio sample from the SDK to make sure it wasn't one of my files and it doesn't seem to be specific to .aif or .wav files. For me, the issue still occurs even if no rate changes were applied, and if no callbacks were set (I've just included one here to count the iterations, it can be commented out).

I found the same as you, that using setPlayRange() makes the issue go away (and why I hadn't personally encountered this sooner if it isn't new).

In my sample, I included a loop iteration counter and it seems to stop after 77 76 iterations consistently in the simulator for me. I also reproduced on device but in some other tests, it would take longer than 76.

loop-issue-repro-v2.zip (6.9 KB)

local loopPlayer = playdate.sound.sampleplayer.new("sounds/Clav.aif")

local iterationCount = 1
loopPlayer:setLoopCallback(function()
  print("sound loop " .. iterationCount)
  iterationCount += 1
end)
loopPlayer:play(0)

function playdate.update()
end

Also, thanks for great SDK

Agreed completely! :partying_face:

(Edit: Fixed the iteration count and output (off-by-one :man_facepalming:))

1 Like
3

Seems to be explained in Sample rate bug that causes SamplePlayers to get "stuck" playing - #2 by dave — and perhaps the fix is on the way!

4

I've got a fix in for that linked problem, but I can't reproduce @inc3pt's problem in that demo, either with the current working build or with 1.12.3. :thinking:

I guess we'll just have to wait and see if 1.13 fixes it, hopefully won't have to wait too much longer. :crossed_fingers:

2 Likes
5

@dave Here’s a simple test case for 1.13 that shows that the issue persists. Just let it run and it will stop eventually despite reporting that it’s still playing. In my last test it happened after 18 minutes and 50 seconds.
1.13-sample-player.zip (885.6 KB)

PS: Why do they all stop at the same time? :thinking:

6

The bug happens when we get to the end of an ADPCM file and there's a sample or two that we still have buffered from the last decode. It's not a common condition, so in this case it took over 1000 loops before it hit it. In other words, you just got lucky :stuck_out_tongue:

7

Then how do I change my game to not get lucky? :thinking:

8

It's a function of the length of the file, so the worst way to fix it would be trimming the files sample by sample until they no longer hang. Setting a loop range might have the same effect, come to think of it. Either way, that'd involve letting it run for an hour or so each time to see if you've dodged the bug.

An easier fix is switch to plain PCM audio for these. They're not that long so it shouldn't have that much impact on the overall file size. I think we'll be getting the fix for this bug into 1.13.2, so you could switch back to ADPCM after that if you want to save some disk/download space.

1 Like