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

Severe Framerate Caps When Using Certain Combinations of Headsets + Audio APIs While Enabling Audio Sync #26

Open
RPGHacker opened this issue Jun 3, 2020 · 1 comment
Labels
bug Something isn't working question Further information is requested

Comments

@RPGHacker
Copy link

Background: I was trying out this ROM hack yesterday and noticed that my framerate was capped at around 50 FPS, making it unplayable. This shouldn't be a matter of just processing power, because my PC has very high specs. In fact, I then went on to test out other hacks - ones that I was able to play just fine on this system previously - and they all had the same 50 FPS cap.

I then went on to try different things and figured out that the cause of this problem is the combination of certain audio APIs with certain audio output devices. My PC speakers died on me yesterday, so I was forced to switch to an USB headset I had lying around. I set up BSNES to use WASAPI with my USB headset. Trying out different audio APIs with the same headset, I could observe that every one of them led to a different framerate cap, all below 60 FPS. Disabling audio entirely or switching the audio output back to my broken PC speakers restored the intended framerate cap of 60 FPS.

It's worth noting that I went on to play the hack in RetroArch + Snes9x core afterwards, which did not show these symptoms, so it seems to be something unique to BSNES. I don't know what could be causing it, though. Maybe some kind of audio syncing. Since this is a USB headset, I suppose it technically counts as its own sound device (rather than using the Sound Blaster Z in my PC), so maybe BSNES uses audio in a way that isn't compatible with all audio devices or something like that.

This USB headset is pretty much from a no-name brand, but I can imagine that other audio devices could lead to similar issues. Also I just went ahead to check if there's an option for audio-syncing, and indeed there is one. When I disable it, the framerate is actually capped at 60 FPS, so that confirms that audio-syncing is the issue here, but I'm not sure whether this can be considered an actual bug or whether this is something that is just inherent to certain audio devices/drivers and that BSNES can't do anything about.

@Screwtapello Screwtapello added bug Something isn't working question Further information is requested labels Oct 15, 2020
@Screwtapello
Copy link
Contributor

Sorry it's taken so long to respond to your report!

bsnes has two ways to limit the speed games run at: video sync and audio sync. Normally you'd only use one or the other — you can use both with Dynamic Rate Control, but I don't think that's available for the WASAPI driver. If you were trying to use both with WASAPI, that might explain some glitchiness - normally it wouldn't glitch that much, but who knows. If you turn off video sync and leave audio sync enabled (the opposite of the combination you found) and things still ran at 60fps, I think that would prove it. If turning off both audio and video sync still leaves bsnes running at 60fps, then either your graphics drivers are force-enabling video sync, or your computer is not fast enough to reliably run bsnes.

Another possibility is that your USB headphones don't support the sample-rate bsnes is using. I think bsnes defaults to generating audio at 48000Hz — but if your headphones only support 44100Hz output, and it plays back the sound at that slower speed, that would limit you to ~55fps with audio sync.

Does any of that help?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants