This can reduce audio latency according to
https://developer.android.com/ndk/guides/audio/opensl/opensl-prog-notes#perform.
Previously we were using the hardcoded values of 48000 Hz and 256 frames
per buffer. The sample rate we use with this change is 48000 Hz on all
devices I'm aware of, but the buffer size does vary across devices.
Terminology note: The old code used the term "sample" to refer to what
Android refers to as a "frame". "Frame" is a clearer term to use for
this, so I've changed OpenSLESStream's terminology. One frame consists
of one sample per channel.
Not sure if we're ever going to want to have more than one of these at
the same time, but these global variables are a code smell nonetheless.
I'm also deleting the existing member variables because they were
unused.
Based on @noahpistilli (Sketch) PR:
https://github.com/dolphin-emu/dolphin/pull/12567
Fixed the Windows support and the heisenbug caused by uninitialized
members.
Config system integration finalized.
Removed VolumeChanged signal, as ConfigChanged will trigger what is needed.
Only applies UpdateSoundStream to things that can change during emulation.
Settings::SetVolume might no longer be used, but left it in.
Cubeb logs a message at CUBEB_LOG_NORMAL verbosity every time you start
or stop a stream which can get a bit annoying when using frame advance
at Dolphin's default verbosity.
`count` is the number of stereo samples to write (where each stereo sample is two shorts), while `BUFFER_SIZE` is the size of the buffer in shorts. So `count` needs to be multiplied by `2`, not `BUFFER_SIZE`. Also, when this check was failed, the previous code just clobbered whatever was past the end of the buffer after logging the warning, which corrupted `basename`, eventually resulting in Dolphin crashing.
This affected Datel's Wii-compatible Action Replay, which uses a block size of 2298, or 18384 stereo samples, which is 36768 shorts, which is bigger than the buffer size of 32768. (However, the previous commit means that only one block is transfered at a time, eliminating this issue; fixing the bounds check is just a general safety thing instead of an actual bugfix now.)
This should reduce (but not completely eliminate) gradual audio desyncs in dumps. This also allows for accurate sample rates for the GameCube.
Completely eliminating gradual audio desyncs will require resampling to an integer sample rate, as nothing seems to support a non-integer sample rate.
