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 (https://mednafen.github.io) 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: https://hg.libsdl.org/SDL/rev/ffd52bb02bcc 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.

--ryan.

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.

--ryan.

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 https://hg.libsdl.org/SDL/rev/dcb6c57df2fc and should resolve this bug.

--ryan.