search

mupen64plus / mupen64plus-core

Core module of the Mupen64Plus project
1.32k stars 258 forks source link

Fixed the state of resamplers. #223

Open YellowOnion opened 7 years ago

YellowOnion commented 7 years ago

I'm not sure what the problem is exactly, but the only resampler working at the moment is trivial on the windows rebuilt binary, and it sounds like ass.

If this code can't be maintained properly, perhaps consider ditching the trivial resampler and SRC and implement speex-3 across all platforms, I really don't see the need to have such a configuration anymore, CPUs are plenty fast, that most modern computers can easily run something as stupidly good as speex-10 with minimal overhead.

ricrpi commented 7 years ago

Mupen64plus is also used on some embedded development boards e.g. Raspbery pi so you cannot assume that you have a high spec CPU.

YellowOnion commented 7 years ago

@ricrpi I would be curious to see just how much of an impact speex-{1-3} has on a Raspberry Pi, Android has used a resampler since it was running on hardware slower than the Raspberry Pi.

Considering how badly Mupen performs on my computer compared to PJ64 while using a quality resampler, This seems like a pretty good case for premature optimization.

I keep coming back to Mupen64 hoping it has improved in the audio department, the god awful delay can be fixed, but the primary reason for this bug is the lack of options available for the windows build.

richard42 commented 7 years ago

Can you be more descriptive than "sounds like ass"? Are there gaps or cutouts in the audio playback? Noise? Low sampling rate? What happens when you select resamplers other than "trivial"?

The audio/video delay problem is not a function of the audio resampler, but a design problem related to a lack of communication between the audio buffering and the speed limiter. It's on my list of things to fix but requires a major change in the API, so I will integrate the audio handler and get rid of the plugin at the same time.