Error: "Out-of-range float value for pa_latency: "0.5" (must be between 0.000000 and 0.250000, inclusive); reverting to 0"

[ghost]

MAME version

0.254

System information

Windows 10 Home, 64-bit, version 22H2, USA, US English Installed RAM 8.00 GB AMD A6-5200 APU with Radeon(TM) HD Graphics 2.00 GHz

INI configuration details

mame -cc

Emulated system/software

No response

Incorrect behaviour

pa_latency is broken. Mame docs and the PDF page 120 says:

"-pa_latency latency

Choose the buffer size for PortAudio output; this is specified in seconds. Lower numbers have less latency but may increase stutter in the sound. Decimal places are supported. Try starting from 0.20 and decrease or increase until you find the best number your hardware and OS are capable of handling.

The default is 0.

Example: mame suprmrio -sound portaudio -pa_api "Windows WASAPI" -pa_device "NX-EDG27 (NVIDIA High Definition Audio)" -pa_latency 0.20"

But anything higher than a 0.25 second setting spits out this error in the terminal: Out-of-range float value for pa_latency: "0.5" (must be between 0.000000 and 0.250000, inclusive); reverting to 0

That was running from cmd mame sf2hf -sound portaudio -pa_latency 0.5 This error does not show up using verbose output to a txt file. The docs are very clear that values can be decimal and are in seconds.

Expected behaviour

pa_latency should respect values "as advertised", or the docs should have some kind of range listed for the values similar to the mednafen documentation layout.

Steps to reproduce

run any game in mame from terminal with command mame -sound portaudio -pa_latency 0.26 or mame -sound portaudio -pa_latency 1

Additional details

I stumbled across this trying to figure out my problem with the speakers switching from the other bug report and I was looking at the verbose output and saw the error show.

I think audio_latency is broken using portaudio too, because it doesn't increment the buffers in even steps when incrementing the value from 0 to 5. The docs don't really explain how the 2 latency settings interact together with portaudio, only how audio_latency should increase for stuff like xaudio, dsound, etc.

running on default mame.ini and running through all 6 audio_latency values produced the following in the logs: mame sf2hf -v -w -sound portaudio -pa_api "Windows WASAPI" -audio_latency 0 PortAudio: Sample rate is 48000 Hz, device output latency is 3.33 ms PortAudio: Allowed additional buffering latency is 3.00 ms/144 frames

mame sf2hf -v -w -sound portaudio -pa_api "Windows WASAPI" -audio_latency 1 PortAudio: Sample rate is 48000 Hz, device output latency is 3.33 ms PortAudio: Allowed additional buffering latency is 10.00 ms/480 frames

mame sf2hf -v -w -sound portaudio -pa_api "Windows WASAPI" -audio_latency 2 PortAudio: Sample rate is 48000 Hz, device output latency is 3.33 ms PortAudio: Allowed additional buffering latency is 30.00 ms/1440 frames

mame sf2hf -v -w -sound portaudio -pa_api "Windows WASAPI" -audio_latency 3 PortAudio: Sample rate is 48000 Hz, device output latency is 3.33 ms PortAudio: Allowed additional buffering latency is 50.00 ms/2400 frames

mame sf2hf -v -w -sound portaudio -pa_api "Windows WASAPI" -audio_latency 4 PortAudio: Sample rate is 48000 Hz, device output latency is 3.33 ms PortAudio: Allowed additional buffering latency is 70.00 ms/3360 frames

mame sf2hf -v -w -sound portaudio -pa_api "Windows WASAPI" -audio_latency 5 PortAudio: Sample rate is 48000 Hz, device output latency is 3.33 ms PortAudio: Allowed additional buffering latency is 90.00 ms/4320 frames

values 0 - 5 and we have in milliseconds: 3, 10, 30, 50, 70, 90. Those are only even steps of 20 from 10 onward, why 3 and 10 for values 0 and 1??? If I set it to 0, it shouldn't be adding 3ms, zero is zero. I want the mimimum allowed WITHOUT adding unnecessary latency.

The last bit of weirdness I noticed tonight, why does this increase my device output latency to 10ms? It should be 3.33ms: mame sf2hf -v -w -sound portaudio -pa_api "Windows WASAPI" -audio_latency 0 -pa_latency 0.00002 PortAudio: Sample rate is 48000 Hz, device output latency is 10.00 ms PortAudio: Allowed additional buffering latency is 0.02 ms/1 frames

Adding a smidge (0.00001) to the value of pa_latency and output latency for the device is normal again???: mame sf2hf -v -w -sound portaudio -pa_api "Windows WASAPI" -audio_latency 0 -pa_latency 0.00003 PortAudio: Sample rate is 48000 Hz, device output latency is 3.33 ms PortAudio: Allowed additional buffering latency is 0.03 ms/1 frames

Saw this in an old commit: https://github.com/mamedev/mame/commit/1ccdfb873a480c0306ac0553cf9298036f79d2d7 Suggestion for very-low-latency mode on portaudio

• Needed to keep audio in sync when playing rhythm game machines such as konami system 573. This is because the lowest audio_latency currently supported (audio_latency 1) introduces at least 10 ms of variable latency. I am unsure how to go about this without breaking backward compatibility so I set it to work only when audio_latency is 0 (which was previously ignored by mame itself and was treated equivalent to audio_latency 1). I am aware that setting audio_latency to 0 is not supported by many mame frontends, but this change seems natural. Otherwise, would it be better to add a new mame.ini option, or to automatically enable this low-latency mode when pa_latency is set lower than, say, 0.01 (10ms), which would break people's configurations if they already rely on the old behavior?

It seems like this "very-low-latency mode" doesn't work as expected, as why would -audio_latency 0 -pa_latency 0.00002 cause device output latency to be a flat 10.00ms but changing to -audio_latency 0 -pa_latency 0.00003 leaves it as it should be (at the lowest this machine can go which is 3.33ms for 48000 samplerate and 3.63ms for 44100). Seems like it should be the other way around somehow. And why is the 44100 sample rate higher latency on a machine I had set to the same output rate???

The logic here doesn't make a lot of sense to me, and neither does the math (mix up the values with audio and pa_latency for yourself, the results don't make sense), and the basic lack of any real explanation on the topic just adds to the confusion. I don't see how a user is expected to deal with it even after reading the manual, and I'm a firm believer in "RTFM" ;) Over 6 years portaudio has been a thing in mame and lacked good explanation and examples, kind of inexcusable for a project of this scope at this point. It's a documentation project which lacks good documentation about itself in many areas. Makes me wonder how many people were driven off by this very sort of thing and into the arms of the "dishonorable competition" which I shall only ever refer to here as RA. You know who I mean. I'm sorry to say I don't see a very bright future for things if this keeps up.

I had to either error audio_latency with an invalid value to even know what values it would accept in the terminal (as those aren't listed in your docs) since the UI doesn't even show the user this kind of thing, or go to another site for the info such as the now kind of outdated https://easyemu.mameworld.info/mameguide/command_line/osd_sound/audio_latency.html and more recent https://mamedoc.readthedocs.io/pt/latest/commandline/commandline-all.html#mame-commandline-audiolatency

The docs also lie about the default value of audio_latency, it is 2 in a default mame.ini but the doc says: https://docs.mamedev.org/commandline/commandline-all.html#mame-commandline-audiolatency -audio_latency

The exact behavior depends on the selected audio output module. Smaller values provide less audio delay while requiring better system performance. Higher values increase audio delay but may help avoid buffer under-runs and audio interruptions.

The default is 1. <----wrong, more user confusion

I would expect there to be some semblance of consistency here when changing values for audio_latency just like with the other sound ouput settings (even steps of value x), something that when put on a graph would look like a nice slope from 0-5 with even stepping.

Speaking of 0, setting audio_latency to 1 does the same thing as 0 on xaudio2.

I understand one cannot make something have absolute zero for latency all around, but if the user desires no additional latency on top of what their machine is minimally capable of, then that should be honored.

[ghost]

Meditating on this a bit more, I think what is ultimately desired here, and I'm trying to think in a way a casual emulator user would, is that audio_latency should be more like this example when used with portaudio:

audio_latency 0 = minimum the user machine allows (with a note stating as much) audio_latency 1 = 10ms or 20ms audio_latency 2 = 20ms or 40ms audio_latency 3 = 30ms or 60ms audio_latency 4 = 40ms or 80ms audio_latency 5 = 50ms or 100ms

Take that value, and then add pa_latency value to that. Device output latency should stay at the machine's minimum (i.e. 3.33ms or whatever) for audio_latency at 0 and with a pa_latency of 0.010 would create additional latency of 10ms so the result is 13.33ms. audio_latency at 1 + pa_latency 0 would get 10ms, and both values at 0 should produce the minimum the machine can handle (i.e. 3.33ms).

If I understand the code for pa_latency correctly it seems that it acts as breathing room for the audio in case of slight desyncing? (pa_latency controls allowable audio jitter). But yeah, the way it is now with that unexpected padding being applied to the device output (10ms vs expected 3.33) and then additional being applied (weirdness example from initial post above -audio_latency 0 -pa_latency 0.00002) really makes for a long day.