Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns Arcade1Up Try the site in https mode Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news

  

Author Topic: Higher granularity for audio latency setting  (Read 5362 times)

0 Members and 1 Guest are viewing this topic.

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Higher granularity for audio latency setting
« on: March 08, 2013, 06:24:38 pm »
Hi Calamity,

I noticed that the audio latency setting in MAME/MESS for Windows is (simply) a multiplication factor applied to the default stream_buffer_size. By forcing only integer values to be used for the setting, it's unfortunately a bit crude at that. Changing the setting from 1 to 2 -doubles- the audio latency, by approximately doubling the stream buffer size from 18432 to 37888 (there's rounding on whole buffer blocks but that's not important). A setting of 3 triples the latency  by tripling the stream_buffer_size to 57344. These are quite large (too large IMO) steps.

Maybe you've experienced that a buffer setting of 2 is fine, but 1 is not, and you'd rather have the latency somewhere inbetween? Well at least I have. Currently that is not possible, but I've made a simple patch that changes the relevant variables to float and allows you to set the latency with higher granularity, e.g. a value of 1.7. It also prints the buffer value so that you can get a sense of the actual changes.

I've attached the diff. Maybe it's interesting for you also, and possibly useful to include in GM?

Cheers!

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Higher granularity for audio latency setting
« Reply #1 on: March 11, 2013, 06:06:37 am »
Hi Dr.Venom,

This is definitely interesting. From reading your post I understand that setting audio latency to 1 is just not enough? I mean, can you notice audio glitches when setting this to 1? Can you provide me with a test case, so I can double check here? Because I never noticed anything so I believed (wrongly) that this setting was there only for old under-powered systems.

Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: Higher granularity for audio latency setting
« Reply #2 on: March 11, 2013, 10:11:45 am »
Hi Calamity,

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.


Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Higher granularity for audio latency setting
« Reply #3 on: March 11, 2013, 11:25:02 am »
I see, however you are adding lag to the sound by doing so... I even thought that I'd just use the fractional value of audio latency to set something like 0.5 or so :)
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: Higher granularity for audio latency setting
« Reply #4 on: March 11, 2013, 11:28:42 am »
Why is increasing the granularity adding lag?


Edit: The purpose is to find the lowest latency (=lowest audio latency setting) while still having zero buffer over-/underruns. IMO raising the granularity just provides the possibility to achieve just that?
« Last Edit: March 11, 2013, 11:32:06 am by Dr.Venom »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Higher granularity for audio latency setting
« Reply #5 on: March 11, 2013, 12:13:16 pm »
Why is increasing the granularity adding lag?

No, I didn't say that. It's increasing the audio latency setting what adds lag, so you might end up entering the noticeable audio lag territory just in order to get rid of some unnoticeable buffer overruns.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: Higher granularity for audio latency setting
« Reply #6 on: March 11, 2013, 12:49:47 pm »
My perspective was actually lowering the lag as much as possible below 2 while maintaining 100% accuracy. But I see your perspective. You're willing to sacrifice 100% audio for the benefit of lower latency, as long as you can't perceive the lost frames of audio. Which of course is an equally valid point of view.

Anyway, after these opposing views ;), would it make sense to add the patch to GM?

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Higher granularity for audio latency setting
« Reply #7 on: March 13, 2013, 06:27:48 am »
Anyway, after these opposing views ;), would it make sense to add the patch to GM?

Yes, I will probably add it...
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: Higher granularity for audio latency setting
« Reply #8 on: March 13, 2013, 10:05:45 am »
Great.

Please note that to actually be able to lower the audio latency to values below 1 a change to the patch is needed:
Code: [Select]
// sound options
{ NULL,                                           NULL,       OPTION_HEADER,     "WINDOWS SOUND OPTIONS" },
// { WINOPTION_AUDIO_LATENCY "(1.0-5.0)",                "2.0",        OPTION_FLOAT,    "set audio latency (increase to reduce glitches)" },
           { WINOPTION_AUDIO_LATENCY "(0.1-5.0)",                "2.0",        OPTION_FLOAT,    "set audio latency (increase to reduce glitches)" },


I've attached the adjusted patch. 

The MAME code actually limits the lower buffer to a (byte) size of 1024, which is very close to realtime. But the currently used DSOUND API in Windows won't come -anywhere- close without running into very perceivable problems...


P.S.
<rant on emulation perfection on, ;-)>
Getting close to such low latencies for Windows will only be possible when MAMEDEV add the WASAPI pro-audio* interface to MAME. I'm aware that Wasapi is W7+ only, but now that Windows 7 is getting to >50% penetration I guess it becomes more worthwhile for them to consider adding it besides the dsound api. Well let's hope so...

*http://msdn.microsoft.com/en-us/library/windows/desktop/dd370784%28v=vs.85%29.aspx
<rant off>
« Last Edit: March 13, 2013, 10:11:13 am by Dr.Venom »

deathterrapin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 24
  • Last login:Today at 08:07:56 am
Re: Higher granularity for audio latency setting
« Reply #9 on: March 13, 2013, 02:32:04 pm »
Getting close to such low latencies for Windows will only be possible when MAMEDEV add the WASAPI pro-audio* interface to MAME. I'm aware that Wasapi is W7+ only, but now that Windows 7 is getting to >50% penetration I guess it becomes more worthwhile for them to consider adding it besides the dsound api. Well let's hope so...

ASIO would be another option. Using ASIO4ALL drivers I can get smooth sound output with only a 64 sample buffer (the minimum it will let you have IIRC) on something I wrote a while ago. That works on older versions of Windows too. Sadly I don't really have the energy to go delving into the MAME code myself.
« Last Edit: March 13, 2013, 02:38:08 pm by deathterrapin »

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: Higher granularity for audio latency setting
« Reply #10 on: March 13, 2013, 08:41:03 pm »
ASIO would also be an option, but I have to be honest that my personal experience with ASIO, when it comes to emulation, isn't that good. Could probably depend on how it's implemented though.

My experience with the "WASAPI" audio mode with emulation comes from WinUAE, where Toni Wilen has created an implementation which allows for extremely low latency when using the "WASAPI-Exclusive" setting.

Possibly if there would be someone with the time, energy and most of all skill, then the WASAPI code from WinUAE could possibly be ported (https://github.com/tonioni/WinUAE). Toni's a good guy, so he probably wouldn't mind (if politely asked for permission ofcourse).