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: GM ASIO ALPHA 0.171  (Read 93931 times)

0 Members and 1 Guest are viewing this topic.

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #40 on: December 10, 2014, 06:40:50 am »
I just did this one for fun. It's the original pre-alpha build (gm 155).

Thought you guys would get a kick out of it. The audio is playing out of both cabinets. Stereo on GroovyMAME, Mono on the MVS hardware.

GroovyMAME is on the right, btw.



Awesome! :)

Thanks for this!

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #41 on: January 05, 2015, 11:13:07 pm »
It will be interesting to try this with the new 0.015d patch that I believe should provide a more stable speed percentage when using frame_delay.

SwitchRes 0.015d seems to have done away with the neodrift speed oscillations (and probably many other games too) mentioned in http://forum.arcadecontrols.com/index.php?topic=141869.0, which is great!

After doing lots (and lots) of testing, I think I can conclude that frame_delay seems to affect different computers/installations differently, at least in regards to audio sample generation. This also appears dependent on what game is run, and if d3d/ddraw is used.

I've done tests on two computers. One i3 3.4GHz with a Z97 chipset, and a Core 2 Duo 2.95GHz with a 945PL chipset. Both are running Windows 7, with the latest CRT emudriver and GM156/SwitchRes 0.015d.

The 'speed spikes' mentioned in http://forum.arcadecontrols.com/index.php?topic=141869.0 still appear on the i3 when using d3d, however, when using ddraw, they don't. So pbobble (-bench 30 = 1835%) with frame_delay 8 and ddraw work perfectly on this rig. However, with the same settings (fd8 and ddraw), msword (-bench 30 = 2564%) does not. Even though no speed spikes appear with ddraw, sample generation seem to be intermittently delayed (see attached image), which will lead to underruns, if aiming for the best possible latency.

No speed spikes appear on the Core 2, with neither d3d nor ddraw, but the intermittent sample generation delay problem seems to appear here also.

What to make of this? At this point, I don't really know. Some games work great with frame_delay, and some, which probably should, don't. Switching between D3D/DDraw seems to affect the sample generation process in some way. Also, increasing -asio_holdoff to 1536 will help mitigate buffer over-/underruns, but will add 16 ms of latency.

In conclusion, if anyone's interested in testing frame_delay in combination with ASIO, and you're getting too many over-/underruns, try switching between ddraw and d3d, since it seems to have an effect. Also try setting -asio_holdoff 1536. And, just like Calamity says, frame_delay should be used as a per-game setting. If tweaking for a particular game, I'm sure good results can be achieved, at the probable cost of higher latency.

Unrelated to frame_delay, after doing more tests on XP, the conclusion is that ASIO4ALL does not work nearly as good as on 7, so you really need a proper ASIO-capable card (such as an old SB with the kX driver) for stuff to work. Using the i3, the Z97 chipset does not support XP, and on this setup I couldn't get kX to work satisfactorily (also, the 64-bit GM+ASIO executable didn't even launch, and spat out an illegal instruction exception in powf). On the Core 2, kX worked just fine with a 128 sample ASIO buffer. So mileage with XP will undoubtedly vary.

Edit: I've just noticed more stuff which seems somewhat weird, I'm gonna have to do some tests and report later on.
« Last Edit: January 06, 2015, 03:26:26 am by intealls »

bulbousbeard

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 522
  • Last login:August 25, 2015, 11:58:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #42 on: January 06, 2015, 01:28:38 am »
What about ASIO for normal computer setups with normal computer monitors?

Are you planning to do a standalone diff for baseline MAME?

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #43 on: January 06, 2015, 01:50:46 am »
What about ASIO for normal computer setups with normal computer monitors?

Are you planning to do a standalone diff for baseline MAME?

Not right now. There's still lots of stuff that needs fixing, and even more stuff that needs figuring out. But in time I could make a separate patch for mainline.

In the meantime, GM can be configured to work just fine with a normal monitor.

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #44 on: May 20, 2015, 10:39:45 am »
Intealls, thank you for your work on this.  It has given me yet another thing to obsess over.  I'm coming here from the Raw Input vs Direct Input Lag thread because of a finding there that involves your ASIO patch. 

Luckily, with a default mame.ini generated from the .156 build you've posted here, there is no additional lag compared to vanilla GroovyMAME.  Input is reflected on the 1st or 2nd frame following input with frame_delay 9 set.  However, with the ASIO4ALL solution, I had to set my asio_holdoff value to 1152 to avoid obviously audible overrun/underrun issues.  This results in increasing lag so that input is often reflected on the 3rd frame after it is received.  I don't really understand how asio_holdoff works.  You mentioned that increasing it can increase latency, but I assumed you meant audio only.  It appears to affect input latency as well.  Perhaps you were already aware.

So, now I'm trying to come up with a lower latency solution so I can use your patch without incurring additional lag, little as it is.  Like I said, I'm obsessed now.  It looks like getting a new cheap motherboard without any PCI slots was a mistake, because I can't use my old Creative cards with the kX driver without one.  I have a USB Behringer UCA202 that has a native ASIO driver that I am able to play through with programs like Foobar2000, but I haven't figured out how to get it working with your patch yet.  Batool recognizes it after I registered its asio DLL in Windows, but it doesn't seem to like the syntax I am using for testing.  I'll play with it some more and post some results later, but I think I'll end up trying to find a PCI express card that will work with it instead.  Is anyone aware of any?

*Edit - Additional testing showed that there is currently no good evidence that ASIO settings impact input lag.  It shouldn't cause any issues in this area.
« Last Edit: May 29, 2015, 11:55:39 am by vicosku »

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #45 on: May 20, 2015, 06:26:32 pm »
I found a Realtek native ASIO driver.  It plays audio through foobar2000's ASIO component successfully on my ALC888.  Perhaps others will find it useful.  I assume these might provide better latency than ASIO4ALL, but really have no idea.  Installation Instructions are included.

Realtek_ASIO_driver_v1.0.0.1.zip

However, I can't get BATool64.exe or GroovyMAME to recognize this driver either.  the -asio_log option produces no log in this scenario.  All I get from the -V output is "ASIO: Unable to initialize device 0"

*Edit - Nevermind.  The included driver appears to be 32-bit only.
« Last Edit: May 21, 2015, 10:08:19 am by vicosku »

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #46 on: May 28, 2015, 01:15:38 pm »
I had to set my asio_holdoff value to 1152 to avoid obviously audible overrun/underrun issues.  This results in increasing lag so that input is often reflected on the 3rd frame after it is received.  I don't really understand how asio_holdoff works.  You mentioned that increasing it can increase latency, but I assumed you meant audio only.  It appears to affect input latency as well.  Perhaps you were already aware.

Strange, how are you measuring the latency? The only modification I can think could possibly affect the input latency is that the audio is updated at a higher frequency than with vanilla GM.

asio_holdoff simply waits until there are N samples in the buffer before starting playback. Setting it to 1152 waits until there are 24 milliseconds worth of audio ready to be played before beginning playback. This will help when the audio updates come from GM somewhat irregularly, which seems to be the case when using a high frame_delay value with a demanding game.

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #47 on: May 28, 2015, 01:53:50 pm »
Thanks for the reply!  So when you say that "it" waits 24 milliseconds for enough audio to be ready, what do you mean, exactly?  Should the sound only be 24 ms slower, or the emulation entirely?  24 ms is roughly the amount of input lag that was added when I used increased audio_latency and asio_holdoff values with ASIO4ALL, so I'm suspicious. 

The tests were performed as shown in the Raw Input vs Direct Input thread.  An LED is wired to a button and then a CRT screen is recorded with a high-speed camera to observe the delay from when a button is pressed until the result shows on-screen.

You can see that the first results I posted in that thread are about 1 frame laggier than the subsequent results.  This was with DirectDraw and Frame_Delay 0.  I compared the mame.ini file to a fresh one and the only differences were video ddraw, asio_holdoff, and audio_latency.  ddraw vs d3d with identical frame_delay values had basically identical input latencies in my testing, so that led me to test the Asio settings, which I was able to confirm caused additional lag.

However, I've done so many tests that my memory is becoming foggy, and I wonder if I made a mistake somewhere with conflicting INI settings regarding frame_delay.  I didn't save or post my subsequent tests, which was a mistake.  I'll run more tests and share my logs and configurations so you don't just have to take my word for it.

Otherwise, since the last time, I've tested my older Core2Duo system with both a first-gen Audigy with the Kx driver and an Asus Xonar DG with Uni drivers.  The lowest ASIO latencies available with each work well in most cases with audio_latency 2.0 and asio_holdoff 832.  The Xonar is kind of weird, because only the lowest setting of 1ms works without audio drops, which your logs report as a latency of 96.  Higher latencies all seem to cause issues.

I picked up a PCIe Xonar DGX for my newer system yesterday and it works okay.  I haven't gotten to test much, but I get better results with d3d and frame_delay than DirectDraw now.  Neo Geo games with Frame Delay 8 are completely solid, as are CPS 1 and 2 games at frame_delay 9, but Street Fighter 3 3rd Strike at Frame_delay 8 is erratic despite bench speeds around 1500%, unfortunately.  It runs great without frame_delay enabled.  I need to do some more testing and see if I'm okay with leaving it off for this game and using Direct Draw.  The reduced lag of Direct Draw vs d3d alone is probably fine, but I've just become obsessed with having the lowest possible latencies for input and sound.

By the way, what ASIO settings would be equivalent to Direct Sound with Audio_Latency 1.0? 
« Last Edit: May 28, 2015, 01:55:48 pm by vicosku »

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #48 on: May 28, 2015, 03:00:54 pm »
Thanks for the thorough reply!

So when you say that "it" waits 24 milliseconds for enough audio to be ready, what do you mean, exactly?  Should the sound only be 24 ms slower, or the emulation entirely?

Only the audio should be affected.

However, I've done so many tests that my memory is becoming foggy, and I wonder if I made a mistake somewhere with conflicting INI settings regarding frame_delay.  I didn't save or post my subsequent tests, which was a mistake.  I'll run more tests and share my logs and configurations so you don't just have to take my word for it.

Thanks, I certainly know the feeling. :)

Otherwise, since the last time, I've tested my older Core2Duo system with both a first-gen Audigy with the Kx driver and an Asus Xonar DG with Uni drivers.  The lowest ASIO latencies available with each work well in most cases with audio_latency 2.0 and asio_holdoff 832.  The Xonar is kind of weird, because only the lowest setting of 1ms works without audio drops, which your logs report as a latency of 96.  Higher latencies all seem to cause issues.

I picked up a PCIe Xonar DGX for my newer system yesterday and it works okay.  I haven't gotten to test much, but I get better results with d3d and frame_delay than DirectDraw now.  Neo Geo games with Frame Delay 8 are completely solid, as are CPS 1 and 2 games at frame_delay 9, but Street Fighter 3 3rd Strike at Frame_delay 8 is erratic despite bench speeds around 1500%, unfortunately.  It runs great without frame_delay enabled.  I need to do some more testing and see if I'm okay with leaving it off for this game and using Direct Draw.  The reduced lag of Direct Draw vs d3d alone is probably fine, but I've just become obsessed with having the lowest possible latencies for input and sound.

By the way, what ASIO settings would be equivalent to Direct Sound with Audio_Latency 1.0?

I don't remember if the audio_latency parameter affects the ASIO implementation with the build posted here. I could patch up the latest GM and refresh my memory a bit, I'll probably have it done sometime this weekend. But -audio_latency 1.0 with dsound seems to add about 75 milliseconds compared to ASIO, which would correspond to an -asio_holdoff setting of about 3600.

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #49 on: May 29, 2015, 09:01:51 am »
3600, eh?  That's good to know.  Thanks!

I have good news!  It looks like I was wrong.  Using Audio_latency 5.0 and asio_holdoff 1152 does not appear to introduce input lag.  I can only reproduce results that consistently show input on the 3rd gameplay frame with frame_delay 0, so I assume when I was testing before, I still had frame_delay set at 0 through INI confusion.  All of my asio results with frame_delay 9 and d3d were in the 1-2 frame range. 

Videos Zip
Logs and INIs zip
Speadsheet with frame counts (240FPS.  Divide by 4 and discard decimal for the gameplay frame input was shown on)

*Edit - Removed some speculation.
« Last Edit: May 29, 2015, 11:52:58 am by vicosku »

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #50 on: May 29, 2015, 11:02:03 am »
. I could patch up the latest GM and refresh my memory a bit, I'll probably have it done sometime this weekend.

I forgot to mention that I would greatly appreciate this.  I haven't investigated how to do it myself yet.  Now that MAME and MESS are merged as of .162, would this mean that the ASIO functionality would work with MESS drivers as well?

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #51 on: May 30, 2015, 04:02:37 pm »
. I could patch up the latest GM and refresh my memory a bit, I'll probably have it done sometime this weekend.

I forgot to mention that I would greatly appreciate this.  I haven't investigated how to do it myself yet.  Now that MAME and MESS are merged as of .162, would this mean that the ASIO functionality would work with MESS drivers as well?

Thanks alot for your tests. Great to know that the ASIO stuff does not seem to affect the input latency.

Building with ASIO is a pain right now, since MAME just recently updated its build system, and GMASIO (64-bit) needs to be built using Visual Studio. I also had to employ a couple of truly terrible hacks to the sound structures, since there were changes there a couple of versions back.

Nonetheless, here's 0.162 :) It includes both MAME and MESS.

http://www.mediafire.com/download/n2jyl6f773p530h/gmame162-asio.zip

EDIT: Also, -audio_latency 5.0 is no longer needed. The only parameter that affects the latency is -asio_holdoff (and of couse the latency of the ASIO driver).
« Last Edit: May 30, 2015, 04:11:50 pm by intealls »

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #52 on: May 30, 2015, 08:08:30 pm »
Awesome, thank you!  SNES and Genesis are the only MESS drivers I've tried so far, but they're working great!  Also, with .156 and The Xonar DGX, I was getting crashes with CPS1 and CPS2 games at Frame_delay 9 with d3d (My machine can't handle frame_delay 9 with these drivers with ddraw, it seems).  These crashes are gone now!  I had an easy way to reproduce them before, but can't cause a crash regardless now.  I don't even get any overruns or underruns with default asio_holdoff 832 in these drivers anymore.  I'll have to play with it a lot more, but initially this seems really great.  Thanks again!

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #53 on: May 30, 2015, 08:28:03 pm »
Awesome, thank you!  SNES and Genesis are the only MESS drivers I've tried so far, but they're working great!  Also, with .156 and The Xonar DGX, I was getting crashes with CPS1 and CPS2 games at Frame_delay 9 with d3d (My machine can't handle frame_delay 9 with these drivers with ddraw, it seems).  These crashes are gone now!  I had an easy way to reproduce them before, but can't cause a crash regardless now.  I don't even get any overruns or underruns with default asio_holdoff 832 in these drivers anymore.  I'll have to play with it a lot more, but initially this seems really great.  Thanks again!

No problem :)

Again, thanks a lot for the tests. Also, did you have to use batool to get a good calibration with the Xonar DGX? Thinking of picking one up.

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #54 on: May 30, 2015, 08:43:51 pm »
You're welcome! Yes, I ran a long calibration.  With HPET off in BIOS and bcdedit /set useplatformclock true, I get 48002.356.  The Xonar DG on my older Core2Duo machine got a similar setting.  I assume the DGX is the same card, just with a PCI express interface.  The variations are worse than my Realtek onboard sound, but within 1hz.  I'll run another calibration and share the log.  It probably doesn't work as well your audigy/kx driver solution, but the low dpc latency option in the UNi Xonar drivers seems pretty good.  Here are a few examples of games and settings I'm using to get to the point where I can't hear any problems, and few or no overruns/underruns show in logs.  This is on a Haswell Pentium G3258 at 4.6Ghz

Neo Geo - asio holdoff 832, frame_delay 8, ddraw
CPS1 and 2 - asio holdoff 832, frame_delay 9, d3d (ddraw performs badly at FD9 on my machine, but d3d is great and stable with .162 in these drivers)
CPS3 - asio holdoff 1536, frame_delay 8, ddraw
Cave - asio holdoff 1536, frame_delay 9, ddraw

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #55 on: May 31, 2015, 10:06:12 am »
Here is the log of my overnight calibration of the Xonar DGX.  The variation is less than I originally stated.

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #56 on: May 31, 2015, 12:31:44 pm »
Here is the log of my overnight calibration of the Xonar DGX.  The variation is less than I originally stated.

Now that's a proper calibration. :) I'm gonna order one to try out, since they're decently priced.

Neo Geo - asio holdoff 832, frame_delay 8, ddraw
CPS1 and 2 - asio holdoff 832, frame_delay 9, d3d (ddraw performs badly at FD9 on my machine, but d3d is great and stable with .162 in these drivers)
CPS3 - asio holdoff 1536, frame_delay 8, ddraw
Cave - asio holdoff 1536, frame_delay 9, ddraw

I'm gonna try these settings on my i3 3.4 GHz, to see if the same performance can be achieved on a completely different rig, with ASIO4ALL/kX (and soon DGX). Hopefully, I'll see similar results. If the same results can be shown consistently across multiple rigs/drivers, a 'known working settings' table could be put together.

Thanks again and please continue to post your findings, it's greatly appreciated! :)

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #57 on: May 31, 2015, 05:12:11 pm »
Good luck!  A known working settings table sounds like a good idea.

I've been doing some more testing with this new MAME version to make sure no input lag snuck into my favorite games.  I have found one scenario where it has, but maybe it was there before.  I get basically no over or underruns with direct draw and Neo Geo games, so I've been trying it with everything.  However, with Street Fighter 3 Third Strike at frame_delay 8 and asio_holdoff 1536, it appears that it suffers from around 1 extra frame of lag compared to Direct3D.  Perhaps this is actually what I ran into with some of my other testing, rather than accidentally having frame_delay set at 0.  Here are the videos.  Rather than include logs, I recorded myself opening the CPS3.INI file to show that the video setting changed from d3d to ddraw.  This was the only change between tests.  I counted the first 20 samples of each video and include some statistics below.

sfiii3u D3D
Next Frame Responses - 8/20
3rd Frame Responses - 0/20

sfiii3u DDRAW
Next Frame Responses - 1/20
3rd Frame Responses - 2/20

I've recorded several sfiii3u tests and have gotten similar results each time. I've never seen a 3rd frame result with d3d at frame_delay 8 in this game.  I ran the same test with Neo Geo (garouh) at Frame_Delay 8 and asio_holdoff 832.  In that test, I didn't see any significant input delay difference between d3d and ddraw.  I can't get next-frame input response with Neo Geo no matter what I do, and the spread of 2nd and 3rd frame responses appeared equal.  Audio stability is basically perfect with ddraw here, so I'm happy to keep using it.   

Even though Calamity has said that ddraw keeps the CPU busy longer than d3d, I'm not sure what the difference would be in the sfiii3u case.  -bench 300 showed 1640% with d3d and 1633% with ddraw, which are both significantly better than my Neo Geo performance, so I don't know.  Anyway, I'll be trying to use d3d whenever I use frame_delay, unless ASIO performance with ddraw is significantly superior and I can confirm no increased input delays. 


« Last Edit: May 31, 2015, 05:14:14 pm by vicosku »

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #58 on: June 01, 2015, 07:42:04 am »
I've been doing some more testing with this new MAME version to make sure no input lag snuck into my favorite games.  I have found one scenario where it has, but maybe it was there before.  I get basically no over or underruns with direct draw and Neo Geo games, so I've been trying it with everything.  However, with Street Fighter 3 Third Strike at frame_delay 8 and asio_holdoff 1536, it appears that it suffers from around 1 extra frame of lag compared to Direct3D.  Perhaps this is actually what I ran into with some of my other testing, rather than accidentally having frame_delay set at 0.  Here are the videos.  Rather than include logs, I recorded myself opening the CPS3.INI file to show that the video setting changed from d3d to ddraw.  This was the only change between tests.  I counted the first 20 samples of each video and include some statistics below.

sfiii3u D3D
Next Frame Responses - 8/20
3rd Frame Responses - 0/20

sfiii3u DDRAW
Next Frame Responses - 1/20
3rd Frame Responses - 2/20

I've recorded several sfiii3u tests and have gotten similar results each time. I've never seen a 3rd frame result with d3d at frame_delay 8 in this game.  I ran the same test with Neo Geo (garouh) at Frame_Delay 8 and asio_holdoff 832.  In that test, I didn't see any significant input delay difference between d3d and ddraw.  I can't get next-frame input response with Neo Geo no matter what I do, and the spread of 2nd and 3rd frame responses appeared equal.  Audio stability is basically perfect with ddraw here, so I'm happy to keep using it.   

Ok, have you done these tests against vanilla GM? If vanilla GM and GMASIO do not behave the same, I've got homework to do. :)

EDIT: A while back, I put together a script to help me test various ASIO-related settings, if you're only testing for over/underruns, you might find them useful (rename to .bat).
« Last Edit: June 01, 2015, 08:45:51 am by intealls »

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #59 on: June 01, 2015, 08:54:52 am »
I just tested vanilla GroovyMAME .162 and the results were the same.  I also tested sf2 at frame_delay 9, which I can run at a much higher percentage than sfiii3u, and it also had the same results.  Out of the first 20 frame counts, all showed response on the 2nd gameplay frame except one, which showed on the 3rd.  GM 1.56 with the ASIO patch also behaves the same.  I don't think it matters, but all my testing has been with RawInput.

At the moment, I don't know of any evidence that shows Direct Draw allowing for next-frame response times in GM with frame_delay 9.  At least, I can't produce any on this Windows 7 machine.  Of course, it produces much less lag than d3d when frame_delay is not used, so I leave it as my default in mame.ini for when I have not configured a game-specific ini.  My tests show d3d responds on the 5th or 6th frame in this case, vs direct draw's 2nd or 3rd.  Later when I have a chance to upload the videos, I'll make a post in the input lag thread.

Thanks for the batch files!  I'll try them out.

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #60 on: June 01, 2015, 09:24:16 am »
I just tested vanilla GroovyMAME .162 and the results were the same.  I also tested sf2 at frame_delay 9, which I can run at a much higher percentage than sfiii3u, and it also had the same results.  Out of the first 20 frame counts, all showed response on the 2nd gameplay frame except one, which showed on the 3rd.  GM 1.56 with the ASIO patch also behaves the same.  I don't think it matters, but all my testing has been with RawInput.

At the moment, I don't know of any evidence that shows Direct Draw allowing for next-frame response times in GM with frame_delay 9.  At least, I can't produce any on this Windows 7 machine.  Of course, it produces much less lag than d3d when frame_delay is not used, so I leave it as my default in mame.ini for when I have not configured a game-specific ini.  My tests show d3d responds on the 5th or 6th frame in this case, vs direct draw's 2nd or 3rd.  Later when I have a chance to upload the videos, I'll make a post in the input lag thread.

Thanks for the batch files!  I'll try them out.

Ok, thanks. I'm gonna thoroughly try the settings you posted later today, I've done some preliminary tests and so far I see a strong correlation with the results you see.

It's actually quite awesome to be able to play deathsml with fd 9 :)

Once again, thanks for your tests, I've been scratching my head over the ddraw/d3d differences ever since I started developing this patch, so it's great that more light is being shed on the matter.

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #61 on: June 01, 2015, 10:37:36 am »
It's actually quite awesome to be able to play deathsml with fd 9 :)

You've confirmed this?!  I think I can only run at FD5 or so on my 4.6ghz 2 core Haswell g3258 with -mt.  If you're referring to when I said I could run "cave" games at fd 9, I meant the "cave" driver used for their 90s games like Donpachi.  I can't run any cv1k games at speeds necessary for fd9, though I was only going by speed and I don't think I've bothered trying it out. 

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #62 on: June 01, 2015, 11:07:35 am »
It's actually quite awesome to be able to play deathsml with fd 9 :)

You've confirmed this?!  I think I can only run at FD5 or so on my 4.6ghz 2 core Haswell g3258 with -mt.  If you're referring to when I said I could run "cave" games at fd 9, I meant the "cave" driver used for their 90s games like Donpachi.  I can't run any cv1k games at speeds necessary for fd9, though I was only going by speed and I don't think I've bothered trying it out.

Hmm, with ddraw it seems OK. With D3D, not so much.

Code: [Select]
### DDRAW ###

ASIO: Game is running at 60.000000 Hz, screen at about 60.000000 Hz
ASIO: Driver kX ASIO initialized with latency 64,
      sample rate 48000.00, compensated sample rate 48007.601563,
      buffer size of 32768 samples
      holdoff is 832 samples
Region ':maincpu' created
Region ':game' created
Region ':ymz770' created
window_proc: WM_PAINT
window_proc: WM_PAINT:END
Starting Deathsmiles (2007/10/09 MASTER VER) ':'
  (missing dependencies; rescheduling)
Starting SH-3 (big) ':maincpu'
Starting RTC-9701 ':eeprom'
Starting Serial Flash ':game'
Starting Video Screen ':screen'
Optional device 'finder_dummy_tag' not found
Starting palette ':palette'
Starting Speaker ':lspeaker'
  (missing dependencies; rescheduling)
Starting Speaker ':rspeaker'
  (missing dependencies; rescheduling)
Starting Yamaha YMZ770 ':ymz770'
Starting EP1C12 Blitter ':blitter'
Starting Deathsmiles (2007/10/09 MASTER VER) ':'
  (missing dependencies; rescheduling)
Starting Speaker ':lspeaker'
Starting Speaker ':rspeaker'
Starting Deathsmiles (2007/10/09 MASTER VER) ':'
ASIO: QPC freq: 14318180
Average speed: 99.79% (121 seconds)
Switchres: restoring DALDTMCRTBCD320x240x0x60 - Modeline "320x240_60 1
5.64KHz 59.91Hz" 6.63 320 336 368 424 240 242 245 261   -hsync -vsync
ASIO: Average callback timeslice usage: 0.322818
ASIO: Overrun/underrun: 5/1
window_proc: WM_NCACTIVATE
blit_lock = TRUE
window_proc: WM_DESTROY
blit_lock = TRUE

C:\framedelaytset\vicosku>vmame64 -asio_cal_freq 48007.6 -asio_device
1 -video ddraw -frame_delay 9 deathsml -priority 1 -rompath y:\mame015
3\roms -v

### D3D ###

ASIO: Game is running at 60.000000 Hz, screen at about 60.000000 Hz
ASIO: Driver kX ASIO initialized with latency 64,
      sample rate 48000.00, compensated sample rate 48007.601563,
      buffer size of 32768 samples
      holdoff is 832 samples
Region ':maincpu' created
Region ':game' created
Region ':ymz770' created
window_proc: WM_PAINT
window_proc: WM_PAINT:END
Starting Deathsmiles (2007/10/09 MASTER VER) ':'
  (missing dependencies; rescheduling)
Starting SH-3 (big) ':maincpu'
Starting RTC-9701 ':eeprom'
Starting Serial Flash ':game'
Starting Video Screen ':screen'
Optional device 'finder_dummy_tag' not found
Starting palette ':palette'
Starting Speaker ':lspeaker'
  (missing dependencies; rescheduling)
Starting Speaker ':rspeaker'
  (missing dependencies; rescheduling)
Starting Yamaha YMZ770 ':ymz770'
Starting EP1C12 Blitter ':blitter'
Starting Deathsmiles (2007/10/09 MASTER VER) ':'
  (missing dependencies; rescheduling)
Starting Speaker ':lspeaker'
Starting Speaker ':rspeaker'
Starting Deathsmiles (2007/10/09 MASTER VER) ':'
ASIO: QPC freq: 14318180
ASIO: Channel sync disparity 147 at about update 14025
Average speed: 99.42% (139 seconds)
Switchres: restoring DALDTMCRTBCD320x240x0x60 - Modeline "320x240_60 1
5.64KHz 59.91Hz" 6.63 320 336 368 424 240 242 245 261   -hsync -vsync
ASIO: Average callback timeslice usage: 0.312359
ASIO: Overrun/underrun: 238/64
window_proc: WM_NCACTIVATE
blit_lock = TRUE
window_proc: WM_DESTROY
blit_lock = TRUE

C:\framedelaytset\vicosku>vmame64 -asio_cal_freq 48007.6 -asio_device
1 -video d3d -frame_delay 9 deathsml -priority 1 -rompath y:\mame0153\
roms -v

EDIT: Why this is, I don't know. I suppose it shouldn't work, since in-game speeds oscillate wildly between 200% -> 1500%.

EDIT AGAIN:

I'm actually getting terrible performance with this game with frame_delay 0 and d3d. (ASIO: Overrun/underrun: 899/163)

And roughly the same with d3d + frame_delay 9 (ASIO: Overrun/underrun: 709/324)

Although, with ddraw + frame_delay 0 (ASIO: Overrun/underrun: 1/0)

and ddraw + frame_delay 9 (ASIO: Overrun/underrun: 6/1)

I'm doing 180 second tests with the following parameters -frame_delay 0/9 -asio_holdoff 832 -asio_log -video ddraw/d3d -seconds_to_run 180 -autorol -nodisable_nagscreen_patch -nodisable_loading_patch -nosleep -priority 1
« Last Edit: June 01, 2015, 12:00:55 pm by intealls »

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #63 on: June 02, 2015, 08:53:34 am »
Weird!  My results are sort of similar, but not as good.  Here are my results with the switches you posted.

deathsml ddraw + frame delay 9 - ASIO: Overrun/underrun: 206/10

It's playable without any noticeable issues, except for an occasional obvious burst of overruns.  None of the other games I've tried allow stable frame_delay 9 performance for any amount of time with either d3d or ddraw if I'm not over 2000% speed.  Deathsml is a mess at frame_delay 9 and d3d, as I'd expect. 

Direct Draw's behavior with frame_delay seems a bit unpredictable regarding both audio performance and input latency.  I'd like to get a comparison of input lag between d3d and ddraw at various frame_delays in this game, but pressing f2 doesn't give me a nice test screen like with other games.  I tried to use the character select screen to test, but in videos it's difficult to see when input is registered. I'll have to try something else later. 

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: GM ASIO PRE-ALPHA
« Reply #64 on: June 02, 2015, 11:16:35 am »
My understanding of this is that drawing a new frame with ddraw+vsync takes a nearly constant amount time (even if longer than d3d), however with d3d+vsync it takes a much more variable amount of time to render a frame. And this difference must be impacting the stability required for ASIO audio computations, while it's not so relevant at the scale we normally need for GroovyMAME.
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

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #65 on: June 03, 2015, 04:30:18 pm »
Thanks, Calamity.  That's a simple and sensible explanation. 

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #66 on: June 06, 2015, 12:15:43 pm »
I broke out the PS eye camera today to do some tests on DeathSmiles and frame_delay with DirectDraw.

Using frame_delay 9 + ddraw with this game does not seem to make any discernable difference compared to using fd 0.

Code: [Select]
I counted as follows, frame 0 is when the LED lights up. Frame n is when the game has shifted from the left image in the attachment (measure.jpg) to the right one.

frame [0]        | frame [1 ... n-1] | frame [n]
input sent       | delay             | output on screen

so for a value of 4, it means the following

[0]  | [1] [2] [3] | [4]
sent | .. delay .. | output on screen

fd 0 asio
4, 4, 5, 5, 4, 4, 4, 5, 4, 4, 4, 4, 5, 4, 4, 4, 4, 4, 5, 4, 4, 4, 5, 4, 4, 4

20 4's
 6 5's

fd 9 asio
4, 4, 5, 5, 4, 4, 4, 5, 4, 4, 4, 4, 4, 4, 4, 4, 4, 5, 5, 4, 4, 4, 5, 4, 4, 4

20 4's
 6 5's

fd 9 vanilla
4, 4, 4, 5, 4, 4, 4, 4, 4, 4, 4, 4, 4, 5, 4, 4, 4, 5, 5, 4, 4, 4, 5, 4, 4, 4

21 4's
 5 5's

If anyone wants me to post the videos, I will do so.
« Last Edit: June 06, 2015, 12:17:49 pm by intealls »

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: GM ASIO PRE-ALPHA
« Reply #67 on: June 06, 2015, 04:36:38 pm »
DeathSmiles reacts to input 3 frames after you actually press a key, you can check this with the shift+P method. Relative to your counting it should be frame number [3].

Assuming a decent PC (one that can run this game unthrottled around 1000%) and using frame_delay 9, you should be seeing the game react at frame [3] for some of your samples at least.

I can think of some reasons you might be getting a worse result:

- The frame_delay option only works if -syncrefresh is enabled too. Maybe some ini file might be forcing it disabled? Get a log to check it. Remind the condition is:

Code: [Select]
if (m_framedelay != 0 && m_framedelay < 10 && m_syncrefresh && mode->hactive)
- If the input device is too slow, its own latency could be eating any gain obtained by the frame_delay feature. You can make sure this is not the case by means of the test screen of sf2 which is known to react in the very next frame.

- The cpu takes too long to emulate each frame, which I don't think is the case, otherwise you couldn't be using fd 9 fluently.
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

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #68 on: June 07, 2015, 09:27:26 am »
DeathSmiles reacts to input 3 frames after you actually press a key, you can check this with the shift+P method. Relative to your counting it should be frame number [3].

Assuming a decent PC (one that can run this game unthrottled around 1000%) and using frame_delay 9, you should be seeing the game react at frame [3] for some of your samples at least.

I can think of some reasons you might be getting a worse result:

- The frame_delay option only works if -syncrefresh is enabled too. Maybe some ini file might be forcing it disabled? Get a log to check it. Remind the condition is:

Code: [Select]
if (m_framedelay != 0 && m_framedelay < 10 && m_syncrefresh && mode->hactive)
- If the input device is too slow, its own latency could be eating any gain obtained by the frame_delay feature. You can make sure this is not the case by means of the test screen of sf2 which is known to react in the very next frame.

- The cpu takes too long to emulate each frame, which I don't think is the case, otherwise you couldn't be using fd 9 fluently.

Thanks for the info! I tried sf2 and managed to get next frame input response (which is damned awesome to see btw :) ), so I'm pretty sure the rig works as intended (it's a Teensy configured as USB keyboard, which alternates between pressing left/right when the LED lights up/goes out).

I'm not sure the rig is able to run the game at 1000%, a -bench 180 gives 570%, but when running the game, it seems fine at 100% with fd9, which seems strange.

The linked video (can be opened with VirtualDub with ffdshow installed) is a run with fd 9 + d3d with vanilla GM, beginning with sf2. Sf2 shows that input can be registered to appear at the next frame (starting at about 35 seconds in). I then chose 'Select new machine' and started deathsml, but I cannot get next frame (third frame) input registration. Could it be because the rig is simply not able to actually run it fast enough? Although it does seem strange it seems to run at 100%.


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: GM ASIO PRE-ALPHA
« Reply #69 on: June 07, 2015, 11:01:12 am »
Today I noticed something interesting. I recorded sf2 on my Core2Duo with fd 9 and couldn't seem to get next frame input response. I knew it should be capable because I've seen it in the past but for some reason it didn't work today. Tried -priority 1, -nosleep, increasing usb polling rate, all to no avail. I pressed f12 to see unthrottled speed and it was 700-800%, less than I had assumed for this game. Then I lowered fd to 7 and, finally, I could see input in next frame in my recording. I almost sure this has been the key factor, but as it often happens, after too many tests it gets a bit confusing. So it might turn out that using a too high value of fd is counter-productive.
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

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #70 on: June 07, 2015, 11:35:42 am »
Today I noticed something interesting. I recorded sf2 on my Core2Duo with fd 9 and couldn't seem to get next frame input response. I knew it should be capable because I've seen it in the past but for some reason it didn't work today. Tried -priority 1, -nosleep, increasing usb polling rate, all to no avail. I pressed f12 to see unthrottled speed and it was 700-800%, less than I had assumed for this game. Then I lowered fd to 7 and, finally, I could see input in next frame in my recording. I almost sure this has been the key factor, but as it often happens, after too many tests it gets a bit confusing. So it might turn out that using a too high value of fd is counter-productive.

Thanks for the quick reply!

This must be what's happening. From now on, I will make doubly sure the rig is actually capable of running the game at 1000%+ speeds when using fd 9, for expected operation.

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: GM ASIO PRE-ALPHA
« Reply #71 on: June 07, 2015, 05:23:53 pm »
Hi intealls,

Many thanks for creating your ASIO patch for GroovyMAME and trying to nail it to perfection. All of your work is -greatly- appreciated. I hope this will become part of the default GroovyMAME distribution.

From my first impressions it's working really well in many cases, audio latency is close to perfect. I can also confirm some of your and vicosku earlier findings, that there is (or seems to be) a difference in stability when running in ddraw vs d3d, and a variation in how low a buffer can be set for various drivers.

I've been reading much of the test results in this thread with great interest.  With regards to possible unstable results for high framedelay values, I also wanted to share some thoughts that popped into my mind.

1. Haze once said that frame rendering time can be pretty variable within a single driver.
I.e. even with a high unthrottled speed for a single driver, if you start to look at the individual frame rendering times, they show a lot of variation.  Just imagine it as being that unthrottled speed of a driver is 1000%, but some frames render at double of that and other at half of that (or even worse variation...)

For framedelay, knowing unthrottled speed is thus not enough. It's only an average of the quick and the slowly rendered frames. What we actually would need to know is the rendering time of the frames that took the most time in the unthrottled speed test. For example it should spit out an extra statistic besides the unthrottled speed. For example the time of the slowest 1 percentile frames rendered. That would create a much better math to base the maximum frame_delay value on.

2. We're not conscious enough of the impact of jitter and microstutter, which causes infrequent hick-ups in the video rendering pipeline.
There's an incredible amount of debate on this topic, but I'll just pick one which has some nice graphs in there to illustrate the issue:
Analysing Stutter – Mining More from Percentiles
Interestingly it has some code at the bottom of the page to create the percentile pictures from raw FRAPS dumps. Apparently FRAPS logs the time beween Present() calls. Search google images for "fraps microstutter" and the issues becomes apparent quite quickly also.

I'm glad that Calamity posted his results, where he mentions how setting a too high value of fd can be counter-productive. Back when I did a lot of testing on framedelay my findings led me to the conclusion that regardless of very high values of unthrottled speed for a driver, if you ran it long enough, a very high framedelay value would cause issues. To quote from a thread back then:

Quote from: Dr.Venom
Do take notice that there'll  be individual frames that take much higher than the average. You don't want those frames to be skipping when setting the frame_delay to a too high value. "Wait" command on PC can also sometimes take longer than the wait value itself. Both combined are basicly the reason for the safety margin that the rule of thumb also accounts for. So even if your games run really really fast unthrottled (2000%+) , I would advise against setting it to a value higher than 8. What if you set it too high? Then it will be randomly starting to miss vertical blank for frames. You'll notice this by irregular video, audio and/or -added- input delay instead of lowered input delay.

Currently I think that 1. and 2. mentioned above may be a cause of "random" issues with audio buffer over- and underruns at tight latency and issues with high framedelay values. Possibly 2. is worse for D3D than it is for ddraw.

I guess the analogy is that by setting very tight latency on both audio and input response (high framedelay), it's like driving a rocket powered bicycle. It works as long as the road is straight, but it doesn't allow for any bends. With 1. and 2. in place I tend to think we're not driving that straight road.

But, ofcourse, we would need evidence on 1. and 2. in the groovymame context before coming to conclusions.

Regardless of this, thanks again for your work on this patch, it's a real joy to run GM with such low audio latency :)

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #72 on: June 08, 2015, 02:01:35 pm »
Hi intealls,

Many thanks for creating your ASIO patch for GroovyMAME and trying to nail it to perfection. All of your work is -greatly- appreciated. I hope this will become part of the default GroovyMAME distribution.

Thanks :) Currently, the ASIO stuff makes GM tricky to build, and with the changes done to the sound system in MAME, some aspects are suboptimal from a code standpoint. Looking ahead, I think the right way to go about low latency audio is to do a native WASAPI implementation.

From my first impressions it's working really well in many cases, audio latency is close to perfect. I can also confirm some of your and vicosku earlier findings, that there is (or seems to be) a difference in stability when running in ddraw vs d3d, and a variation in how low a buffer can be set for various drivers.

I've been reading much of the test results in this thread with great interest.  With regards to possible unstable results for high framedelay values, I also wanted to share some thoughts that popped into my mind.

1. Haze once said that frame rendering time can be pretty variable within a single driver.
I.e. even with a high unthrottled speed for a single driver, if you start to look at the individual frame rendering times, they show a lot of variation.  Just imagine it as being that unthrottled speed of a driver is 1000%, but some frames render at double of that and other at half of that (or even worse variation...)

For framedelay, knowing unthrottled speed is thus not enough. It's only an average of the quick and the slowly rendered frames. What we actually would need to know is the rendering time of the frames that took the most time in the unthrottled speed test. For example it should spit out an extra statistic besides the unthrottled speed. For example the time of the slowest 1 percentile frames rendered. That would create a much better math to base the maximum frame_delay value on.

2. We're not conscious enough of the impact of jitter and microstutter, which causes infrequent hick-ups in the video rendering pipeline.
There's an incredible amount of debate on this topic, but I'll just pick one which has some nice graphs in there to illustrate the issue:
Analysing Stutter – Mining More from Percentiles
Interestingly it has some code at the bottom of the page to create the percentile pictures from raw FRAPS dumps. Apparently FRAPS logs the time beween Present() calls. Search google images for "fraps microstutter" and the issues becomes apparent quite quickly also.

I'm glad that Calamity posted his results, where he mentions how setting a too high value of fd can be counter-productive. Back when I did a lot of testing on framedelay my findings led me to the conclusion that regardless of very high values of unthrottled speed for a driver, if you ran it long enough, a very high framedelay value would cause issues. To quote from a thread back then:

Quote from: Dr.Venom
Do take notice that there'll  be individual frames that take much higher than the average. You don't want those frames to be skipping when setting the frame_delay to a too high value. "Wait" command on PC can also sometimes take longer than the wait value itself. Both combined are basicly the reason for the safety margin that the rule of thumb also accounts for. So even if your games run really really fast unthrottled (2000%+) , I would advise against setting it to a value higher than 8. What if you set it too high? Then it will be randomly starting to miss vertical blank for frames. You'll notice this by irregular video, audio and/or -added- input delay instead of lowered input delay.

Currently I think that 1. and 2. mentioned above may be a cause of "random" issues with audio buffer over- and underruns at tight latency and issues with high framedelay values. Possibly 2. is worse for D3D than it is for ddraw.

I guess the analogy is that by setting very tight latency on both audio and input response (high framedelay), it's like driving a rocket powered bicycle. It works as long as the road is straight, but it doesn't allow for any bends. With 1. and 2. in place I tend to think we're not driving that straight road.

But, ofcourse, we would need evidence on 1. and 2. in the groovymame context before coming to conclusions.

Regardless of this, thanks again for your work on this patch, it's a real joy to run GM with such low audio latency :)

Thanks for the info, I'll read the linked article more carefully. During development, I seem to remember that some games generated samples very regularly at a fixed interval, but some seemed to do so more irregularly. For instance, DeathSmiles seemed to generate samples at a less fixed interval than say CPS1. So I don't think that the game driver can be left out of the equation (at least for low latency audio), but this needs to be investigated more closely.

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #73 on: June 08, 2015, 03:38:48 pm »
Very interesting posts.  Perhaps I will reduce my frame_delay values for some games to allow for the variability Dr. Venom mentioned.  I haven't done many input lag tests at values lower than 8 or 9.  I might create a table using CPS1, CPS2, and Neo Geo games in order to have a reference at each frame_delay level.  It will be nice to know what kind of compromises are being made when reducing this value.  It'll take me some time though.

I just came by to comment on my Asus Xonar DG/DGX with UNi driver setup, in case anyone was considering them.  After experimenting some more, I can say that these cards allow for somewhat better performance than my Realtek onboard sound with ASIO4ALL, but it's not as good as I would like.  I put a 1st-gen Audigy with kx driver v3551 in my Core 2 Duo machine, and it's a bit better, despite this machine not having the ability to disable HPET.  The kx driver allows for much more flexibility when configuring ASIO, however, which is really nice.  I've ordered an Audigy RX to put in my newer machine.  Hopefully it outperforms the Xonar DGX and will be a decently inexpensive PCI express solution for use with this patch.  I'll report back once it arrives.
« Last Edit: June 08, 2015, 03:54:11 pm by vicosku »

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: GM ASIO PRE-ALPHA
« Reply #74 on: June 08, 2015, 07:23:50 pm »
Thanks :) Currently, the ASIO stuff makes GM tricky to build, and with the changes done to the sound system in MAME, some aspects are suboptimal from a code standpoint. Looking ahead, I think the right way to go about low latency audio is to do a native WASAPI implementation.

That of course would be awesome :)

Thanks for the info, I'll read the linked article more carefully. During development, I seem to remember that some games generated samples very regularly at a fixed interval, but some seemed to do so more irregularly. For instance, DeathSmiles seemed to generate samples at a less fixed interval than say CPS1. So I don't think that the game driver can be left out of the equation (at least for low latency audio), but this needs to be investigated more closely.

The article mostly is about how to measure frametime variability. I always wanted to get more data on this in mame context, but unfortunately I simply lack the time currently to do much testing.
Since maybe you guys are interested in this also, I'll just mention a possible route to getting statistics on frame time variability.

If this would work in the groovymame context, then maybe it could provide us with additional information on:
- D3D versus DDRAW performance
- frametime variability with different mame drivers when using high values of fd (does it cause occasional skipping?)

Apparently FRAPS (registered version?) is able to measure and dump frametimes in a .csv format file. As said FRAPS measures the time between present() calls.
Then there's a tool called FRAFS, on which you apparently can just drop the CSV file and it will produce a nice chart, showing a graph of frametime, plus the fastest and longest frametimes. Something like this:



The FRAFS link http://sourceforge.net/projects/frafsbenchview/files/ has a step by step guide how to set it up to do the frametime measurements.

This youtube video has a "how to", for what it's worth (turn down the volume, to avoid the horrible music in it):  

And this article on Vortez.net provides some interesting reading background on microstutter and measurements (the picture posted here is from that article): GPU Reviews: Why Frame Time Analysis is important

@ Vicosku
Thanks for reporting on the audio cards, much appreciated. From what I understand a "good card" for our purpose may depend more on it having a fast, stable and reliable ASIO driver, then it is depending on the hardware itself. I've had horrible experiences with the Creative ASIO drivers in the past, but it may just have been my specific card/setup.
 

 

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #75 on: June 11, 2015, 10:36:21 am »
Thanks, Dr. Venom.  Using FRAPS to look at frametimes is definitely something I'd like to play with when I have some time.

I have the Audigy RX installed using kX driver version 3552.  It works just like my first gen Audigy.  Unfortunately, performance is really no better than the Xonar DGX for use with this patch, and perhaps a bit worse based on my initial testing.  The main obvious benefit is that the kX ASIO driver allows for much finer sample size configuration compared to the Xonar Uni driver.  The Uni driver only allows 1ms, 2ms, 4ms, 8ms, etc...I'll probably stick with 1ms though and adjust the intermediary buffer on a per-game basis when needed, so the extra control may be of limited use to me.

I've attached some batool logs of 9 passes at 900 seconds and then 30 minute tests of sfiii3 with asio_holdoff 1536.  For the Audigy RX, the largest variation in frequency stability was .117 Hz.  For the Xonar DGX, it was .089.  I admit that the RX test was done using a value from a shorter calibration of 4 passes at 90 seconds each.  This short calibration value used for the test was 47999.375000 versus the long calibration value of 47999.365835972.

Audigy RX - ASIO: Overrun/underrun: 122/56
Xonar DGX - ASIO: Overrun/underrun: 108/51

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: GM ASIO PRE-ALPHA
« Reply #76 on: June 11, 2015, 11:50:00 am »
Hi Dr. Venom, nice to see you back.

Some quick notes:

- It's a well known fact that certain systems have very variable emulation time per frame, this is documented here:

Quote
       * some games have very uneven frame rates; one frame will take
           a long time to emulate, and the next frame may be very fast

   (I'd say using "frame rate" in that context is a bit of an anachronism)

- With regards to D3D and the differences in rendering time per frame. Well, theoretically the "rendering" time with D3D *should* be as deterministic as Direct Draw is. I mean that the "present" call is, according to Microsoft just a flip operation, which simply means changing a memory pointer. So if we believe Microsoft here, it should have zero overhead, but for the required v-sync wait. There is one problem however, the "endscene" call actually returns before the gpu has finished, so when you call "present" probably the gpu still has work pending before it can flip, thus the time it takes.

- But anyway the biggst problem is the hack we use to bypass the frame queue arranged by the ATI drivers when using D3D. If only we got rid of that hack and use SetMaximumFrameLatency instead as suggested by koopah here: http://forum.arcadecontrols.com/index.php/topic,133194.msg1494962.html#msg1494962

Maybe it would be as stable as DDraw is. The catch is it will only work from Vista on. To remove the hack, in src\osd\modules\render\drawd3d.c:

Code: [Select]
m_presentation.PresentationInterval          = ((video_config.triplebuf && window().fullscreen()) || video_config.waitvsync || video_config.syncrefresh))?
D3DPRESENT_INTERVAL_ONE : D3DPRESENT_INTERVAL_IMMEDIATE;

Code: [Select]
/*
// sync to VBLANK
if (window().machine().options().frame_delay() != 0 && ((video_config.triplebuf && window().fullscreen()) || video_config.waitvsync || video_config.syncrefresh))
{
D3DRASTER_STATUS raster_status;
memset (&raster_status, 0, sizeof(D3DRASTER_STATUS));

while (!raster_status.InVBlank)
{
if ((*d3dintf->device.get_raster_status)(m_device, &raster_status) != D3D_OK)
break;
}
}
/*
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: GM ASIO PRE-ALPHA
« Reply #77 on: June 12, 2015, 05:00:05 pm »
Hi Calamity,

Thanks, good to be back. It's great to see all the work and testing done by you, intealls and vicosku, interesting and enjoyable stuff!

Quote
- It's a well known fact that certain systems have very variable emulation time per frame, this is documented here:

Ah, good to have confirmation from the source code documentation.

Quote
- But anyway the biggst problem is the hack we use to bypass the frame queue arranged by the ATI drivers when using D3D. If only we got rid of that hack and use SetMaximumFrameLatency instead as suggested by koopah here: http://forum.arcadecontrols.com/index.php/topic,133194.msg1494962.html#msg1494962

I didn't realize that the get_raster_status hack possibly wouldn't be stable.  From a discussion back then I remember a quote that it ticked like a swiss clock, so I sort of assumed it was working really well for D3D.

But definitely worth a try! If it would work more stable with SetMaximumFrameLatency, then it would quite possiby help the stability for ASIO as well.

Unfortunately I don't have a recent compilation environment set up. If you have a bit of time, would it be too much to ask for you to compile that version and post it here? I guess vicosku, intealls and maybe other users, would be very interested as well. Otherwise I'll get around to it, but just not as soon.

From what I read if you compile an executable with SetMaximumFrameLatency in the code (even when not calling it), then it will crash when run on XP. Just that we know that going forward it would require maintaining/releasing two seperate GM executables.

@ viscosku
Thanks, Dr. Venom.  Using FRAPS to look at frametimes is definitely something I'd like to play with when I have some time.
That would be great, no real idea if it works, but at least it could provide some decent statistics on frame times. Especially on how well the higher fd values actually work, i.e. whether they cause occasional bouts of frameskipping (and thus delayed input latency...)

Good to know that the Xonar DGX and the Audigy are a bit on par with eachother.

The sfiii gaming test results had me wondered a little bit. The over and underruns you're showing are much to large for things working "properly", i.e accurate. Even if you run a game for half an hour, if everything is working ok, you should have very few over-/ underruns.  It's also showing channel sync disparity in the logs. My personal opinion/guess is that your fd value is still to high, and you're sacrificing the emulation quality because of it. (But maybe that is your deliberate choice?) Do you get close to zero buffer over-/underruns when running with fd1?

bulbousbeard

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 522
  • Last login:August 25, 2015, 11:58:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #78 on: June 12, 2015, 11:14:27 pm »
Hi Dr. Venom, nice to see you back.

Some quick notes:

- It's a well known fact that certain systems have very variable emulation time per frame, this is documented here:

Quote
       * some games have very uneven frame rates; one frame will take
           a long time to emulate, and the next frame may be very fast

   (I'd say using "frame rate" in that context is a bit of an anachronism)

- With regards to D3D and the differences in rendering time per frame. Well, theoretically the "rendering" time with D3D *should* be as deterministic as Direct Draw is. I mean that the "present" call is, according to Microsoft just a flip operation, which simply means changing a memory pointer. So if we believe Microsoft here, it should have zero overhead, but for the required v-sync wait. There is one problem however, the "endscene" call actually returns before the gpu has finished, so when you call "present" probably the gpu still has work pending before it can flip, thus the time it takes.

- But anyway the biggst problem is the hack we use to bypass the frame queue arranged by the ATI drivers when using D3D. If only we got rid of that hack and use SetMaximumFrameLatency instead as suggested by koopah here: http://forum.arcadecontrols.com/index.php/topic,133194.msg1494962.html#msg1494962

Maybe it would be as stable as DDraw is. The catch is it will only work from Vista on. To remove the hack, in src\osd\modules\render\drawd3d.c:

Code: [Select]
m_presentation.PresentationInterval          = ((video_config.triplebuf && window().fullscreen()) || video_config.waitvsync || video_config.syncrefresh))?
D3DPRESENT_INTERVAL_ONE : D3DPRESENT_INTERVAL_IMMEDIATE;

Code: [Select]
/*
// sync to VBLANK
if (window().machine().options().frame_delay() != 0 && ((video_config.triplebuf && window().fullscreen()) || video_config.waitvsync || video_config.syncrefresh))
{
D3DRASTER_STATUS raster_status;
memset (&raster_status, 0, sizeof(D3DRASTER_STATUS));

while (!raster_status.InVBlank)
{
if ((*d3dintf->device.get_raster_status)(m_device, &raster_status) != D3D_OK)
break;
}
}
/*

The hack should be a GroovyMAME option IMO. XP is finished. New motherboards don't even have drivers for it anymore. With super resolutions, isn't there basically no downside to using Windows 7 now?

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #79 on: June 13, 2015, 01:55:35 am »
Unfortunately I don't have a recent compilation environment set up. If you have a bit of time, would it be too much to ask for you to compile that version and post it here? I guess vicosku, intealls and maybe other users, would be very interested as well. Otherwise I'll get around to it, but just not as soon.

I would certainly appreciate this.

Quote
The sfiii gaming test results had me wondered a little bit. The over and underruns you're showing are much to large for things working "properly", i.e accurate. Even if you run a game for half an hour, if everything is working ok, you should have very few over-/ underruns.  It's also showing channel sync disparity in the logs. My personal opinion/guess is that your fd value is still to high, and you're sacrificing the emulation quality because of it. (But maybe that is your deliberate choice?) Do you get close to zero buffer over-/underruns when running with fd1?

Yes, sfiii has been frustrating me for the past year, ever since reading your first audio latency posts.  I can use the ASIO patch and get almost no over and underruns in CPS1, CPS2, and Neo Geo games with very low latencies.  sfiii just gives me a lot of trouble in particular, even with asio_holdoff set to 1536 or 2048.  Changing ASIO latency from 96 to 192 reduced the overruns/underruns to 72/50 over 30 minutes with three channel sync disparities, which obviously isn't as low as I would like.  I'm still trying to decide where I want to compromise with this game.  I've tried frame_delay 7 with basically no improvement, but I just ran with frame_delay 1 at your suggestion.  It gave me 99/49 with 6 disparities.  The game fluctuates between 950%-1100% unthrottled in gameplay, and shoots up to 2000% in between rounds and stage transitions.  These are the points when you can most obviously hear the audio issues, if they occur.
« Last Edit: June 13, 2015, 01:57:31 am by vicosku »