Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance locked to ~28FPS with SDL 2.0.9 #3148

SDLBugzilla opened this issue Feb 11, 2021 · 0 comments

Performance locked to ~28FPS with SDL 2.0.9 #3148

SDLBugzilla opened this issue Feb 11, 2021 · 0 comments


Copy link

@SDLBugzilla SDLBugzilla commented Feb 11, 2021

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.9
Reported for operating system, platform: Mac OS X (All), x86_64

Comments on the original bug report:

On 2019-01-30 17:12:19 +0000, Misty De Meo wrote:

The open-source emulator Mednafen ( is experiencing a severe performance issue using SDL 2.0.9. The framerate is capped at approximately 28FPS regardless of how much CPU a game is using. Games should be aiming to hit 60FPS, which is the behaviour for the same version of Mednafen under SDL 2.0.8. I've tracked down the source of the bug with a bisect - it’s this coreaudio-related commit: Reverting that one commit restores performance to what it should be.

The bug occurs on macOS 10.13 and 10.14 using SDL 2.0.9, as well as recent versions of hg tip. It doesn’t reproduce using any older version of SDL.

On 2019-03-06 00:43:51 +0000, Misty De Meo wrote:

Just wanted to check in on this again!

I work on the Homebrew package manager for macOS. I'm considering creating a patch to revert ffd52bb02bcc in our SDL package, since we also package Mednafen. Do you anticipate any negative consequences of doing that?

On 2019-03-17 02:23:24 +0000, Sam Lantinga wrote:

Ryan, how would a coreaudio patch lock framerate?

On 2019-03-17 16:33:35 +0000, Ryan C. Gordon wrote:

(In reply to Sam Lantinga from comment # 2)

Ryan, how would a coreaudio patch lock framerate?

I don't know, but this is on my must-fix list for 2.0.10.

My thinking is that the audio thread creates its own RunLoop to support CoreAudio, and this is causing either a huge CPU load because we're doing something wrong, or it's doing something that causes the main thread's RunLoop to synchronize. I'm looking into it, probably on Monday.


On 2019-03-19 16:48:41 +0000, Ryan C. Gordon wrote:

Ah, I figured it out. In Mednafen's use-case, we accidentally drop audio buffers, which causes the audio callback to fire less, which causes Mednafen framerate to drop, since it only progresses when it can generate more audio.

I'll fix this tonight.


On 2019-03-25 16:27:06 +0000, Ryan C. Gordon wrote:

I ended up backing out the change, which doesn't make me happy, but trying to shoehorn what CoreAudio wants into what SDL wants is just simply less efficient and increases latency, so for now this will have to do. :/

I'll revisit this after 2.0.10 ships, to see if there's a better way to make everything coexist.

The backout commit is and should resolve this bug.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

1 participant