Quote:

---

Audio Latency: This setting tells MAME how accurately it must play sound in accordance to what's taking place on the screen. By raising the number, you are telling MAME to take it's time generating the sound and that it doesn't necessarily have to sync up with the picture if syncing would slow the game down. This is another setting you can play with if you would prefer not to sacrifice the quality of the sound to achieve a full frame rate. But raising this setting increases the likelihood of you seeing an action occur on the screen and hearing it a split moment later.

	{ OSDOPTION_AUDIO_LATENCY "(1-5)",        "2",   OPTION_INTEGER,    "set audio latency (increase to reduce glitches, decrease for responsiveness)" },

Quote:

---

When it was added like that most setups would hiccup if you set it to 1.

Quote:

---

I think 0 is lowest setting.

Quote:

---

It should be corrected, then.

Quote:

---

- Audio latency now admits fractional values (e.g.: -audio_latency 1.5): this makes it possible to find the optimal system specific glitch-safe audio latency value with finer granularity.

Quote:

---

Seriously? Would you explain better? In MAMEUI what happens if you set Audio Latency to 1? It's interesting...

Quote:

---

I don't remember anything about fixing this issue in my FX.

I've noticed that this isn't the first time that you have unintentionally fixed issues without even realizing you've done so. Maybe you're just that good.

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.