List of cores - audio pacing

We need to check for correct audio pacing in cores.

What to look out for:

Cores can be susceptible to crackling audio, particularly when using low frontend audio latency settings.

This is because the core can handle audio output suboptimally.

How many audio samples are expected: look at retro_get_system_av_info() for the parameters - for example, gpsp audio sample rate is 65536 Hz, fps is 59.723. The amount of audio samples to strive for per batch should be: (sample_rate) / (frame_rate).

At the set audio sample rate listed above (gpsp), the frontend expects between 1097 and 1098 audio samples per frame - but the core is sending samples in multiples of 256. This means that the audio output becomes 'desynchronised' with retro_run() - sometimes 1024 samples will get sent to the frontend for the current frame, sometimes 1280 as the core either falls behind or overcompensates. As a result, when the frontend tries to synchronise on audio, jitter can occur - and if the frontend audio buffer is small (when using low latency values), it can sometimes run dry or reach capacity, causing crackling.

• gpSP (Linked PR - https://github.com/libretro/gpsp/pull/165)
• mGBA (Linked PR - https://github.com/libretro/mgba/pull/244)
• O2EM (Linked PR - https://github.com/libretro/libretro-o2em/pull/55 - was not a pacing issue tho )

Start with each remaining core's retro_get_system_av_info() parameters and compare its expected samples per frame with the audio batches it sends. Review the completed gpSP, mGBA, and O2EM entries and confirm whether other cores show the described desynchronisation; done means affected cores are identified and the issue list reflects their status.