Quote:

---

Well the purpose is to run the emulator with zero "Sound: buffer over- / underflows", which is reported on exit after an emulation session when you run MAME/MESS with the "-v" parameter.

Note that each time a sound buffer overflow occurs that the audio samples generated in that frame are skipped into oblivion = audio lost. You can check this by looking at the code in src/osd/windows/sound.c, and search for "// if we're going to overlap the play position, just skip this chunk".

I'm a perfectionist (and I know you are too ), so my test case is *not* only whether or not I can hear a skip, but also whether or not the emulation has actually skipped on audio. Which it does in the case of buffer overruns.

In my experience there a lot of drivers where in an average 5 or 10 minute gaming session the number of buffer overruns will increase when setting the audio latency setting to 1, but the number of overruns will be ~zero when having a setting of 2. When this is the case, being able to set a value somewhere in between might be desirable.

I guess your best test case is to run a game or system you know very well, run MESS/MAME with the "-v" parameter and have audio latency set to 1 and do a gaming session of a few minutes, report the number of buffer overruns (= how many frames of audio have been lost). I would be surprised if that number will be zero... Then do the testcase with audio_latency setting of 2 and see how much -lower- the number of buffer overruns have been. It's probably close to zero. (It might also be worthwhile to do the same for a game / system that taxes your system more than average.)

-If- the above is the case, then I guess you would also benefit of having a higher granularity for the audio latency setting.