When we are synchronizing to audio and waiting for buffers to play back
before continuing in the emulation thread, the SDL and OpenAL audio
drivers currently wait inefficiently in tight loops that consume many
CPU cycles. This PR adds `usleep` calls to these loops.
In the case of the SDL driver, we sleep for ~~the time it takes one
quarter of our prescribed buffer size to play~~ precisely the amount of
time to play our queued audio that's in excess of our prescribed buffer
size.
For the OpenAL driver, it was more difficult for me to determine how to
see exactly how much time we should be waiting since the loop seems to
work slightly differently. One millisecond seemed reasonable given that
the minimum latency is 20 milliseconds, and was sufficient to introduce
significant savings without impacting performance.
Exactly how much CPU use this saves depends on a couple factors;
primarily, the host CPU and the guest core (more demanding cores will
spend a smaller share of time waiting in the audio driver). Reduction
seems independent of audio latency. Here are some sample figures for the
M1 Max:
SNES core (Super Mario World): 95-105% CPU use before, 40-50% CPU use
after with both OpenAL and SDL.
N64 core (Super Smash Bros): 100-110% CPU use before, 60-70% CPU use
after with both OpenAL and SDL.
(macOS's activity monitor measures activity as 'percent of one core',
hence the over-100% figures).
Less demanding cores and more powerful systems will benefit more from
this change, generally.
I tested this pretty thoroughly on my system to make sure that it did
not impact performance on even the lowest 10ms SDL latency on the most
demanding N64 core. However, other people putting this through its
paces, particularly on less powerful systems, would be a good idea, to
make sure that platform differences in `usleep` behavior don't have
unexpected results.
Co-authored-by: jcm <butt@butts.com>
a6d380fb57