We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4481

Summary: Performance locked to ~28FPS with SDL 2.0.9
Product: SDL Reporter: Misty De Meo <mistydemeo>
Component: audioAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2    
Version: 2.0.9   
Hardware: x86_64   
OS: Mac OS X (All)   

Description Misty De Meo 2019-01-30 17:12:19 UTC 
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.
Comment 1 Misty De Meo 2019-03-06 00:43:51 UTC 
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?
Comment 2 Sam Lantinga 2019-03-17 02:23:24 UTC 
Ryan, how would a coreaudio patch lock framerate?
Comment 3 Ryan C. Gordon 2019-03-17 16:33:35 UTC 
(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.
Comment 4 Ryan C. Gordon 2019-03-19 16:48:41 UTC 
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.
Comment 5 Ryan C. Gordon 2019-03-25 16:27:06 UTC 
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.