: Found swap function: glXSwapIntervalEXT. : Detecting screen resolution 2944x1080. : GLX_OML_sync_control and GLX_MESA_swap_control supported, using better swap control method. = Build =Ĭapabilities: MMX MMXEXT SSE1 SSE2 SSE3 SSSE3 SSE4 SSE4.2 AVX AES Log file (default config, just let Mother 3 run for a minute crackles abound) Test different cores/roms to find threshold latencies.Lower audio latency until crackles present (if necessary).Load content on any core with audio output (mGBA worst known offender, not sure why).However, when running such a lightweight core that the system is approximately 90% idle, I would expect there to be enough time to top up the audio buffer at least once per frame, let alone just once every second or third frame.Īlso, on the off chance that this is the intended functionality of the audio system, and I'm just setting the latency too low.isn't audio latency just as important as video latency? RetroArch has made pretty amazing progress in the second category recently, and I'd be happy to see audio get some of the same love. I wouldn't be surprised if the audio began to stutter when the system is near full load, or if there was a rare, intermittent gap under moderate load. If memory serves: even with optimal task priorities, the CPU might still miss deadlines, even if it is often idle. I'm no expert in scheduling theory, but I do know a little bit of it. Changing this value causes more crackles, as expected. 002 Hz, so my vertical refresh rate is set to 60.000. My monitor's measured refresh rate converges to 60.000 ±. Enabling 0-frame hard GPU sync (ironically) requires additional latency, but I found the worst results (crackling at 64 ms) by reverting to a default config file. I have tried changing the output sample rate in RetroArch (48kHz -> 44.1kHz), and I have tried increasing the dynamic audio rate control and the max timing skew (to 3x default values), but without any results. Megaman X also exhibited crackling on bsnes-mercury accuracy, but not in any level-only the level select screen, which can also easily run at or above double speed in fast-forward mode. The English-language patch of Mother 3 crackles heavily on the main menu screen, making it easy to test with, even though the core can run at approximately 700 FPS in fast-forward mode. The issue seems to have nothing to do with the core's CPU utilization. The crackle is less severe in Windows, and latency can be lowered a bit compared to Linux, but remains in excess of two frames (32 ms minimum from light testing). I have reproduced this behavior on Linux Mint 19 and Windows 10 on the same machine. Most of the audio isn't this bad, but these same patterns persist. Additionally, two sections of audio seem to be "spliced" at 27.780-it seems that the audio was abruptly time-shifted without dropping to zero at all. Sometimes the signal appears to have been momentarily "paused", and resumes at the same level it stopped at, but other times it skips either ahead or behind to a completely different level, as if the second chunk of audio has been "time shifted". Most of the time, the audio simply "drops out" for a short, but varying length of time. It affects the left and right channels at the same time. This particularly unlucky run of audio samples shows the full breadth of known failure modes. The distorted audio, however, can be captured with Audacity by monitoring an audio output (e.g. This issue does not affect recorded "video dumps", which contain perfect audio at the emulated system's native sample rate, indicating that the core's output is not at issue here. 20 ms is usually sufficient for most cores, but all mGBA games tested exhibit this audio crackle to some extent at the same latency. Mother 3, running on mGBA, usually requires 48 ms minimum but on occasion has required latencies in excess of 80 ms. The threshold varies by core and by content, and is not always consistent across repeated runs. The audio output from Retroarch is heavily distorted unless the audio latency is set strangely high. Audio output from the core in use must be buffered for some length of time to accomplish this, inducing latency however, a buffer of only a few milliseconds should be sufficient for cores which are not very demanding on the hardware in use. The audio is imperceptibly time-stretched to sync with the video and resampled to the desired output sample frequency without distortion. The audio output from Retroarch sounds the same as on the original console, unless the core is unable to run at full speed. This is most prominent by far in mGBA out of all cores tested, but can be reproduced in other cores as well (albeit at lower audio latencies). Highly audible "pops" and "crackles" occur while a core is running, and can only be remedied by raising the audio latency to excessive levels.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |