Sampleplayer stops playing randomly

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): (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

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. (6.9 KB)

local loopPlayer ="sounds/Clav.aif")

local iterationCount = 1
  print("sound loop " .. iterationCount)
  iterationCount += 1

function playdate.update()

Also, thanks for great SDK

Agreed completely! :partying_face:

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

1 Like

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!

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:

1 Like