That's correct, here's an updated version!
From preliminary (though extensive) testing I have some first findings. My testing has fully concentrated on the genesis driver using a superresolution (-resolution 1280x0) with the game Mega Turrican. This means that GM is actually scaling the internal genesis video by either a factor 4 (genesis 320 wide) or 5 (genesis 256 wide) during each "screenswitch".
The first finding was that the internal scaling on "screenswitches" in the game (as described in an earlier post) would negatively impact the audio stability. The testcase was to wait on the title screen for the demo mode to begin, then press fire (to go back to the title screen). Rinse and repeat. On most of the "screenswitches" an underrun would occur very shortly after the switch. After enough rinse and repeating I realized that I still had my HD 48
30 in my machine from some testing a while ago. Thinking the internal video scaling could be involved, I changed the 4830 to my HD 48
50. And indeed the previous underruns at the screenswitches were completely gone when using the same audio latency test settings. This implies that a fast(er) video card actually matters for sound/ASIO stability, when the driver switches screens and you're using a super resolution.
Next finding has more to do with the ASIO release itself. I found through using the Octave graphs that, on each time after starting the emulator, at the beginning there is some quite significant instability in the number of samples in the audio buffers before stabilizing. This was repeatable over and over regardless of other settings. I finally gathered this had to do with the screenswitch that is done on emulator startup from the PC desktop resolution to the game resolution. I found a way of proving this, as you can enable "show game info" (
skip_gameinfo 0) in the mame.ini, which together with "
disable_nagscreen_patch 1" will physically switch the screen resolution from the desktop resolution to the groovymame resolution (1280x224) *before* starting the game/driver, to show some game information. This means that there's no screenswitching involved anymore at the moment the driver is started. And indeed, following this procedure the large instability in samples in the buffer at startup of the game / driver is gone. This can be repeated over and over.
I've attached two pictures, the one is of startup with screenswitching already done before driver start (skip_gameinfo 0) and the other with screenswitching at startup of the driver (skip_gameinfo 1). You'll see that the first method has a much more stable profile at start (look at the Y scale values at start) than the second. This is the same for both using d3d and ddraw.
This seems to imply, that after a physical screen switch, the screen refresh rate may not be stable for a short time period. If that would be the case (maybe you can verify with your oscilloscope?), you could of course consider implementing a short delay after a physical screenswitch before you enable the audio video synchronization algorithm. My hypothesis is that this would allow for the screen refresh to stabilize, and not actually perform "synchronization" on wrong values. But I may be wrong of course, possibly something completely different is causing this behaviour. Lastly, do note that I have attached both a CRT screen and an LCD to my PC, so maybe that impacts screen switching speed of the CRT.
A third finding was that using "multithreading 1" actually seems to generate less stable audio than having it off. It could especially be seen in the recorded speed against audio update. With multithreading off it would be a flat line, and with it on it would show minor variations in the line.
The fourth finding is that for the genesis driver at least, in combination with my system configuration, I need a marginally larger asio_holdoff (while using a calibrated callback frequency) than the default 864 to get really nice stable results at low driver latency. But once all this finetuning is done, the audio for this driver is running really stable!
P.S. I left testing of high framedelay values out of the equation for now (everything tested with fd 2), as I first want(ed) to get stable results before step by step increasing the fd value and see how that will impact the results. Before testing this, I may wait for your next release first.