Using `setRate()` on a `fileplayer` creates a “avoiding fillOutputBuffers recursion“ warning and huge frame drops

SDK Bug Reports
1

Hey there! I'm using the Lua SDK for my video player and noticed something I've never seen before in my tests. When setting a rate above 1 to a fileplayer, it creates a huge drop of frames on device and the following message in the console:

avoiding fillOutputBuffers recursion

I've attached a simple example (with both the pdx and source) with the following code:

local rate = 1
local audio, audioerr = playdate.sound.fileplayer.new("sample.mp3")
audio:play(0)

function playdate.update()
	playdate.drawFPS(0,0)
end

function playdate.leftButtonDown()
	if rate > 1 then
		rate -= 1
		audio:setRate(rate)
	end
end

function playdate.rightButtonDown()
	if rate < 4 then
		rate += 1
		audio:setRate(rate)
	end
end

Everything works fine in the simulator. But on device, when getting to a rate above 1, everything slows down way down to 5 FPS. I'm fairly certain this didn't happen when I did a lot of tests last year. Perhaps this is since OS 2.0? Not sure if this is intended and if I should post here or in get help. Any help on how to improve this on my side is appreciated.

fileplayerbug.zip (360.9 KB)

2

This changed in 1.12.1. Before that the mp3 decoder would continue running as long as there was space in the output buffer, stalling the run loop entirely if the data is drained as fast as it's produced--which is what happens when you play this file at 2x. In 1.12.1 I added a check for this case, limiting it to 8 cycles. In this case it would underflow and stop playing on the device, but in 2.0 we changed the default "stop on underflow" setting to false on the device to match the simulator, since that caused all sorts of confusion.

One thing that can help with mp3 decoding in cases where CPU is tight is giving the fileplayer a larger buffer so that it can get more done at once. But in this case it's the mp3 decoding that's taking up all the CPU, so that's just delaying the inevitable. Playing this file at 1x puts the CPU load at around 56%--it's pretty clear that 2x playback isn't sustainable.