Implement audio time stretching for mupen64plus-audio-sdl2.

[fzurita]

This is a very heavy modification of mupen64plus-audio-sdl2 that implements audio time stretching. The modification is large enough that it may warrant having a new version of the plugin. This is based on the Android SLES audio plugin which has time stretching.

I have only tried compiling this in windows Visual Studio 2017, the Unix make file has not been touched, so it will probably not build there.

This requires the SoundTouch library. That can be retrieved from here: https://www.surina.net/soundtouch/sourcecode.html

SoundTouch can be compiled using Visual Studio and it can be placed under mupen64plus-win32-deps.

I have only tried a Debug build so far, it seemed to work ok in the base case. I didn't try a case where audio time stretching would be invoked.

[fzurita]

Here are config parameters that may be different from the regular audio-sdl2

PRIMARY_BUFFER_SIZE = 16384
SECONDARY_BUFFER_SIZE = 256
SECONDARY_BUFFER_NBR = 6
SAMPLING_RATE = 0
TIME_STRETCH_ENABLED = True

The lower SECONDARY_BUFFER_NBR is, the lower the latency is going to be. I think I set a default of 20, but lower is probably better for a PC. The higher the number, the less likely there will be any skipping due to speed changes.

SAMPLING_RATE is the desired output sampling rate. The higher the sampling rate, the less distortion will be heard when audio is stretched. If it's set to zero, the game's input frequency will be used.

[fzurita]

Another thing, if the frame limiter is disabled, the game will be paced based on the audio. So the only way to increase game does now is through the SetSpeedFactor API call. A very high speed factor would be like disabling the speed limiter.

[loganmc10]

Wow thanks for doing this. It will take me a while to get around to reviewing this.

Do you think it's possible to modify the SLES plugin and include the SDL2 backend? Like maybe have a sles.cpp and a sdl2.cpp and only compile one depending what backend you want. Then maybe rename it to audio-soundtouch or something?

Then I can just pull from mupen64plus-ae for the audio plugin. It seems like that would make future maintenance easier and have less duplicate code

[fzurita]

Yeah, it's certainly possible. I'll think about it.

[fzurita]

I don't have the privileges to create a new repository under mupen64plus-ae, so I'll probably make it under my my own user name. I'll probably name it mupen64plus-audio-timestretch.

I'm sure it could be useful for low end devices that struggle to maintain speed.

[cascardian]

I'm curious: What is the status of this PR? It would need to be rebased, of course, but is it a viable way overall to deal with mostly shader generation-based popping/popping in general that is/was being reported? Or would something else be better suited?

FWIW, I still get popping on W10 v1909 using Windows' generic drivers on a Realtek ALC1220 chip, but I can very nearly eliminate it with a buffer setting of 4096. I'm also not noticing any additional audio latency with that value. I'm using the Feb 25 build.

Edit: Never mind, in some games it actually seems to make things worse.