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 93960 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!
Re: GM ASIO PRE-ALPHA
« Reply #240 on: July 13, 2015, 09:28:58 am »
Thanks again for posting! Nice! What CPU are you using? My testing rig is using an i3 4130, and I can only get genesis down reliably to fd6.

It's an i7 4790K running at 4.4Ghz.

What is your unthrottled speed for genesis?  For me it runs at about 930% with Mega Turrican using -bench 60.

I noticed in one of your previous logs (here) that your ASIO: QPC freq: is set to 14318180. This is actually the HPET timer frequency (platform clock enabled in Windows 7 & HPET enabled in the bios), which is known to be less stable for emulation timing purposes. Disabling the HPET timer in bios, but still setting platform clock to true in Windows 7 will activate another timer, which may be more stable for your case (or in general even).

Nice trick. :) This is a fabulous game btw. Used to play 1 and 2 on the Amiga.

Great game indeed. You have a good taste in games :) Turrican 2 on Amiga is a true alltime classic in every aspect, still love that one as much today as I did back then.

If you're a fan of Chris Huelsbeck also, he did a remake of his entire Turrican 1 and 2 soundtrack at the end of 2013, see vol 1 here and vol 2 here. Just in case you didn't knew already...

Lastly, could you possibly explain how the current ASIO implementation keeps the audio buffer stable? Does this affect sound quality in any way?

Currently, I try to do as little as possible. As you can see in your tests, if the game speed is consistent (small deviations are ok), it just works. For the next release, I've rearranged the holdoff stuff to provide an audio_latency setting. It's pretty much based on the discussion we've had here - it seemed sensible to base the audio latency upon how many missed callback fetches to allow basically. When set to 1, it attempts to do pretty much what you do in your tests - namely to try and keep the buffer count impossibly low. What it does is that the audio is not being started until the second audio update has been received, and skips almost all samples from the first one. Let's say we get 800 samples per update (60 Hz/48 kHz). When two updates have been received, there are 1600 samples in the buffer. Assuming a latency of 64, we discard 800 - 64 * 2 = 672 samples, being left with 928 in the buffer. We start playback. The next time an audio update arrives, we _should_ have about 128 samples left in the buffer as backup to allow for some leniency (it will vary a bit probably due to update/callback phase shift, might try to get to the bottom of this, not a priority now). The gist is, when we get a refill of samples, we should have eaten away almost all of the ones we have, and as you can see from your tests, that's usually what happens!

Also, when we have more than asio_latency * 3 samples in the buffer, it will count as an overrun, and samples will be discarded to get the count down.

Also, -audio_latency 1 will _not_ try to avoid underruns. If an underrun occurs, everything will have to stabilize itself, and this usually happens pretty quickly. I just played Ristar for an hour and a half with -audio_latency 1 and an apparent 52 underruns, and didn't notice any one of them.

Thanks for explaining. Just to make sure, am I right in assuming that if we have 0 over- or underruns that we then have -perfect- sound (i.e. as (im)perfect as the mame output is), or may there still be other factors in play?

If I look at the log, I see a column that shows varying rate of callback frequency. Does that somehow link into the above?

The underrun behavior has also been changed a bit, when one occurs, instead of giving BASSASIO silence, the last bunch of samples are given again. I think this sounds better, even though when many, many underruns occur, the sound will be sort of metallic, and clearly audible. But still better than silence IMO. Might add an option to toggle this.

Personally I would like the toggle option. Mainly because I'd like to hear if audio is perfect or not, but when it's being masked by some clever stuff that's not possible anymore :)

« Last Edit: July 13, 2015, 09:31:13 am by Dr.Venom »

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 #241 on: July 14, 2015, 10:27:05 am »
Hi Intealls,

I've possibly run into another testcase. When running the PAL version of Mega Turrican in the megadriv driver, it's generating many more overruns than Mega Turrican  in the genesis driver at same settings.

Please see attached graph, which shows the behaviour at framedelay 7.

I checked whether the megadriv driver is slower, but it's actually faster than the genesis driver (megadriv runs at about 1000% unthrottled speed, versus genesis at about 930%), so that shouldn't be the issue?



intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 318
  • Last login:Today at 06:21:27 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #242 on: July 14, 2015, 10:39:25 am »
Thanks again for posting! Nice! What CPU are you using? My testing rig is using an i3 4130, and I can only get genesis down reliably to fd6.

It's an i7 4790K running at 4.4Ghz.

What is your unthrottled speed for genesis?  For me it runs at about 930% with Mega Turrican using -bench 60.

About 600%, so it does make sense that I can only use fd6.

I noticed in one of your previous logs (here) that your ASIO: QPC freq: is set to 14318180. This is actually the HPET timer frequency (platform clock enabled in Windows 7 & HPET enabled in the bios), which is known to be less stable for emulation timing purposes. Disabling the HPET timer in bios, but still setting platform clock to true in Windows 7 will activate another timer, which may be more stable for your case (or in general even).

I need to have useplatformclock set in order to get a consistent calibration frequency, and the motherboard won't let me disable the HPET. :/

Nice trick. :) This is a fabulous game btw. Used to play 1 and 2 on the Amiga.

Great game indeed. You have a good taste in games :) Turrican 2 on Amiga is a true alltime classic in every aspect, still love that one as much today as I did back then.

If you're a fan of Chris Huelsbeck also, he did a remake of his entire Turrican 1 and 2 soundtrack at the end of 2013, see vol 1 here and vol 2 here. Just in case you didn't knew already...

Nice! Gonna have to check those out. It's a bit annoying that Amiga floppy loading seems broken with anything above 0.161, otherwise it would be possible to play them directly in GM. :)

Thanks for explaining. Just to make sure, am I right in assuming that if we have 0 over- or underruns that we then have -perfect- sound (i.e. as (im)perfect as the mame output is), or may there still be other factors in play?

If I look at the log, I see a column that shows varying rate of callback frequency. Does that somehow link into the above?

The underrun behavior has also been changed a bit, when one occurs, instead of giving BASSASIO silence, the last bunch of samples are given again. I think this sounds better, even though when many, many underruns occur, the sound will be sort of metallic, and clearly audible. But still better than silence IMO. Might add an option to toggle this.

Personally I would like the toggle option. Mainly because I'd like to hear if audio is perfect or not, but when it's being masked by some clever stuff that's not possible anymore :)

The varying frequency is due to the game speed estimation slightly changing all the time. It should be very, very difficult to hear. But I've added so that if the game is started with the -speed option, the audio will not be dynamically resampled. But in order to use this you either need to run the game for a while to get the speed percentage to use with -speed, or know the actual refresh rate that's being output to the monitor (dot clock granulated frame rate).

To give an example from a run I recently made regarding the varying playback rate

The game speed was in one instance being reported as 0.999488, then 0.999184. We assume a calibration frequency of 48000 and sample rate of 48000. This means that for the first percentage, the rate was being set to 47975.42 Hz, then 47958.38 Hz. This is a difference of 18.04 Hz. To put this into perspective, this means that a sine wave of 440 Hz would first run at 439.7747 Hz, then 439.618 Hz, a 0.15 Hz difference. I know I certainly would not be able to tell the difference. :)

Hi Intealls,

I've possibly run into another testcase. When running the PAL version of Mega Turrican in the megadriv driver, it's generating many more overruns than Mega Turrican  in the genesis driver at same settings.

Please see attached graph, which shows the behaviour at framedelay 7.

I checked whether the megadriv driver is slower, but it's actually faster than the genesis driver (megadriv runs at about 1000% unthrottled speed, versus genesis at about 930%), so that shouldn't be the issue?

Strange. Thanks for reporting, I'll look into this.
« Last Edit: July 14, 2015, 04:14:18 pm by intealls »

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 #243 on: July 14, 2015, 06:15:00 pm »
I need to have useplatformclock set in order to get a consistent calibration frequency, and the motherboard won't let me disable the HPET. :/

That's a bummer :/

Nice! Gonna have to check those out. It's a bit annoying that Amiga floppy loading seems broken with anything above 0.161, otherwise it would be possible to play them directly in GM. :)

I wish we could. There was a moment that the Amiga driver started to work quite decently. A "bit annoying" is an understatement for me. This is one of the most frustrating parts of the whole MAME project, that at some point a driver seems to improve and stabilize, only to regress beyond the point of usability in next releases.

As another example I've been trying to get PC-Engine CD games to run today with these latest releases, but no go anymore. It either loads a small part, or crashes out directly. Where a number of releases back most titles would work quite well.  Anyway... luckily there are enough drivers that do work great, so let's focus on those ;)

Thanks for explaining. Just to make sure, am I right in assuming that if we have 0 over- or underruns that we then have -perfect- sound (i.e. as (im)perfect as the mame output is), or may there still be other factors in play?

If I look at the log, I see a column that shows varying rate of callback frequency. Does that somehow link into the above?

The varying frequency is due to the game speed estimation slightly changing all the time. It should be very, very difficult to hear. But I've added so that if the game is started with the -speed option, the audio will not be dynamically resampled. But in order to use this you either need to run the game for a while to get the speed percentage to use with -speed, or know the actual refresh rate that's being output to the monitor (dot clock granulated frame rate).

To give an example from a run I recently made regarding the varying playback rate

The game speed was in one instance being reported as 0.999488, then 0.999184. We assume a calibration frequency of 48000 and sample rate of 48000. This means that for the first percentage, the rate was being set to 47975.42 Hz, then 47958.38 Hz. This is a difference of 18.04 Hz. To put this into perspective, this means that a sine wave of 440 Hz would first run at 439.7747 Hz, then 439.618 Hz, a 0.15 Hz difference. I know I certainly would not be able to tell the difference. :)

I agree, I wouldn't either :).  It's at least good to know it works this way and understand the numbers in the log. I like it that the -speed option allows for disabling the dynamic resampling adjustments, even if only for testing purposes.

Looking forward to the next release!

Paradroid

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 687
  • Last login:March 10, 2024, 04:41:43 am
    • SCART Hunter
Re: GM ASIO PRE-ALPHA
« Reply #244 on: July 14, 2015, 08:30:11 pm »
To put this into perspective, this means that a sine wave of 440 Hz would first run at 439.7747 Hz, then 439.618 Hz, a 0.15 Hz difference. I know I certainly would not be able to tell the difference. :)

... and I can't imagine MAME generates a pure sine wave very often either! Mostly these old systems produce such heavily aliased sounds (especially all those crusty old samples in games like sf2) that you have to have a pretty large pitch variation to notice it underneath all that crunchy distortion. :P
My MAME/SCART/CRT blog: SCART Hunter

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 318
  • Last login:Today at 06:21:27 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #245 on: July 15, 2015, 03:30:47 am »
To put this into perspective, this means that a sine wave of 440 Hz would first run at 439.7747 Hz, then 439.618 Hz, a 0.15 Hz difference. I know I certainly would not be able to tell the difference. :)

... and I can't imagine MAME generates a pure sine wave very often either! Mostly these old systems produce such heavily aliased sounds (especially all those crusty old samples in games like sf2) that you have to have a pretty large pitch variation to notice it underneath all that crunchy distortion. :P

True. However, many games generate very clean sounding music (ones that use Yamaha OPN series for instance).

Anyway, here's the new release. Many, many thanks to Calamity for the new frame delay code, and an equal amount of thanks to Dr.Venom for his testing and feedback.

-speed still needs to be set to 0.0 for proper operation. -asio_holdoff is gone, see this post for info about -audio_latency, which is now used instead. A setting of 2 is the default and should work well for most users. The latency is also very much dependent on the ASIO latency setting, see the previously linked post for more info. -mt seems to work well and should probably be used when using -frame_delay. As always, please report issues. The audio update timer has been moved, which may or may not cause issues.

D3D9Ex is not in this release, since it breaks interlaced modes. The m_speed hack and the new frame delay code is in there though.

0.163 r2

Edit: added an updated Octave script for visualizing the ASIO log

Edit: r2.1 fixes a patch apply issue
« Last Edit: July 16, 2015, 04:48:04 pm by intealls »

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 #246 on: July 15, 2015, 10:18:54 am »
Thanks for the update :).

This release is working very well for the various drivers that run in one single screenmode. I've tested a number of arcade games with framedelay of 8 and an audio latency of 2, and they run completely smooth (no over-/ underruns or speed deviations occuring). I've attached the profiles of 1944 and mslug3 as examples. Great stuff!

This release unfortunately doesn't work as good as the R1 release when running Mega Turrican in the genesis driver. I can no longer run this game at fd8, it will cause many overrruns and speed deviations. I think this is caused by the "screenswitching" done by the game/driver. Please see attached profile genesis_megaturrican_fd8_48_2.png. The spikes you see in the graph are when the internal screenswitching takes place.  Changing the latency also doesn't help much.

To further illustrate I ran Ristar in the genesis driver, which runs in one screenmode, and there the profile is smooth when using fd8 and default latency of 2. See attached genesis_ristar_fd8_48_2.png  (mind the scale difference).

Based on this it seems that these "screenswitching" moments are able to put the R2 release off track, where the R1 release would have no issue (see first attached picture in this post). Hopefully this can be ironed out!
« Last Edit: July 15, 2015, 10:23:23 am by Dr.Venom »

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 318
  • Last login:Today at 06:21:27 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #247 on: July 15, 2015, 10:37:44 am »
This release unfortunately doesn't work as good as the R1 release when running Mega Turrican in the genesis driver. I can no longer run this game at fd8, it will cause many overrruns and speed deviations. I think this is caused by the "screenswitching" done by the game/driver. Please see attached profile genesis_megaturrican_fd8_48_2.png. The spikes you see in the graph are when the internal screenswitching takes place.  Changing the latency also doesn't help much.

That's damn strange. In that regard, the two releases should be completely identical. Pretty much the only thing that's been changed is the buffer handling. I actually did a test with platformclock set/unset, and better results were produced having it set. Would you mind giving this a go?

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 #248 on: July 15, 2015, 11:56:31 am »
This release unfortunately doesn't work as good as the R1 release when running Mega Turrican in the genesis driver. I can no longer run this game at fd8, it will cause many overrruns and speed deviations. I think this is caused by the "screenswitching" done by the game/driver. Please see attached profile genesis_megaturrican_fd8_48_2.png. The spikes you see in the graph are when the internal screenswitching takes place.  Changing the latency also doesn't help much.

That's damn strange. In that regard, the two releases should be completely identical. Pretty much the only thing that's been changed is the buffer handling. I actually did a test with platformclock set/unset, and better results were produced having it set. Would you mind giving this a go?

Given extensive testing in the past, I believe I'm already using the best timer for gaming and emulation purpooses. But to make absolutely sure I've tested two additional timers:
- BIOSHPETON+PLATFORMCLOCKTRUE=~14Mhz and
- BIOSHPETOFF+PLATFORMCLOCKFALSE=~3,9MHz

Both timers do not improve the results, please see the attached graphs.  (It would also not have been logical, as nothing changed in my system and the previous release allows me to get the smooth profile at fd8).

Is it still possible for you to create a smooth profile for mega turrican, using the R2 release at FD6 (the max you could do smoothly with R1)?

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 #249 on: July 15, 2015, 12:47:15 pm »
@Dr.Venom, if possible run the same game with R1 too, I wouldn't be surprised it was the computer having a bad day (e.g. different screen configuration).
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
  • ***
  • Online Online
  • Posts: 318
  • Last login:Today at 06:21:27 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #250 on: July 15, 2015, 03:27:16 pm »
@Dr.Venom, if possible run the same game with R1 too, I wouldn't be surprised it was the computer having a bad day (e.g. different screen configuration).

This is probably going to be an issue going forward - with a maxed out frame delay setting and ASIO we're really on the edge, and also much more vulnerable to what other processes on the PC are up to.

Both timers do not improve the results, please see the attached graphs.  (It would also not have been logical, as nothing changed in my system and the previous release allows me to get the smooth profile at fd8).

That's true, if you were able to repeatedly run R1 perfectly and R2 imperfectly in succession. I've done two minor changes to this build. Please try it out and see if it fixes the issue. The run below is done with this build. Latency was set to 64 and audio_latency to 2. The slight drops are due to resolution switching.
« Last Edit: July 15, 2015, 03:52:26 pm by intealls »

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 #251 on: July 15, 2015, 04:47:59 pm »
@Dr.Venom, if possible run the same game with R1 too, I wouldn't be surprised it was the computer having a bad day (e.g. different screen configuration).

Thanks Calamity, that put me on the right track. I went back to the previous release only to find out that it wouldn't run fd 8 anymore. Quitting/restarting, everytime it would start overrunning from the get go.

Looking at the log, I noticed that the modeline that GM reads for 1280x0 from the registry was different than it by default is. The mode had a different dotclock, making it a 60,7Hz mode, where the default installed 1280 modeline should be at 60hz. My guess is that this could be a leftover from a crashed GM, i.e. that the default 60hz modeline wasn't restored normally.  Could it be that GM's dynamic modeline line generation may be influenced by this, causing it to generate a slightly different modeline with different timings?

I restored the default modeline,  then rebooted and he! the previous release would work again with FD8. But... not every time.  Sometimes it will work flawlessly, sometimes it starts overrunning right after the start or at the first screenmode switch. It seems a bit random whether it will or not. The one thing you can bet on, is that if the start is ok, the rest will be too (at least for the time periods I've been testing).  Retesting the R2 release now shows the same behaviour, sometimes it runs smoothly (see the attached graphs), and sometimes it won't.  I''m a bit puzzled by this random behaviour at the start of the emulation, but I guess that's how things work when using really tight settings/timings within a multitasking OS.

This is probably going to be an issue going forward - with a maxed out frame delay setting and ASIO we're really on the edge, and also much more vulnerable to what other processes on the PC are up to.

I think you're right. It's also that the genesis driver runs at 930% unthrottled, so to be honest running FD8 is really pushing it. I'll lower it to FD7 just to be on the safe side.

That's true. I've done two minor changes to this build. Please try it out and see if it fixes the issue. The run below is done with this build. Latency was set to 64 and audio_latency to 2. The slight drops are due to resolution switching.

Thanks, I tried this, but it doesn't seem to make a material difference for the fd8 edge case.  Not an issue for me though, now that I know that the previous release (after all) works the same.

With this out of the way, I have to say that this is a -great-  release, it works really smoothly and is now even easier to configure. I'm loving it all around. Thanks again (to both you and Calamity)!

My vote goes to bringing this out of the pre-alpha stage, at the very least :)

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 #252 on: July 15, 2015, 05:08:52 pm »
@Dr.Venom, that sounds like an unstable dotclock value. Try passing a modeline manually with a slightly different dotclock. Grab the modeline from the game's log, then put it into an .ini (remind "modeline" goes in low case), increasing/decreasing the dotclock value by an unit.

(The fact that there was a leftover in the registry can't affect because GM will override it, unless the modeline_generation option is disabled).
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 #253 on: July 15, 2015, 05:53:51 pm »
@Dr.Venom, that sounds like an unstable dotclock value. Try passing a modeline manually with a slightly different dotclock. Grab the modeline from the game's log, then put it into an .ini (remind "modeline" goes in low case), increasing/decreasing the dotclock value by an unit.

(The fact that there was a leftover in the registry can't affect because GM will override it, unless the modeline_generation option is disabled).

I tried the slightly different dotclocks, but that did not make a difference.

I've been running some longer tests with framedelay 7, with both a latency of 2 and 1, and they run near flawless, see attached graphs. Given this it looks like the fd8 case must really be a case of pushing it too much, given that the unthrottled speed of the driver is "only" 930%. 

filimpan

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 36
  • Last login:November 28, 2017, 01:54:38 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #254 on: July 15, 2015, 08:07:38 pm »
To put this into perspective, this means that a sine wave of 440 Hz would first run at 439.7747 Hz, then 439.618 Hz, a 0.15 Hz difference. I know I certainly would not be able to tell the difference. :)

... and I can't imagine MAME generates a pure sine wave very often either! Mostly these old systems produce such heavily aliased sounds (especially all those crusty old samples in games like sf2) that you have to have a pretty large pitch variation to notice it underneath all that crunchy distortion. :P

True. However, many games generate very clean sounding music (ones that use Yamaha OPN series for instance).

Anyway, here's the new release. Many, many thanks to Calamity for the new frame delay code, and an equal amount of thanks to Dr.Venom for his testing and feedback.

-speed still needs to be set to 0.0 for proper operation. -asio_holdoff is gone, see this post for info about -audio_latency, which is now used instead. A setting of 2 is the default and should work well for most users. The latency is also very much dependent on the ASIO latency setting, see the previously linked post for more info. -mt seems to work well and should probably be used when using -frame_delay. As always, please report issues. The audio update timer has been moved, which may or may not cause issues.

D3D9Ex is not in this release, since it breaks interlaced modes. The m_speed hack and the new frame delay code is in there though.

0.163 r2

Edit: added an updated Octave script for visualizing the ASIO log

Do you think it'd be worth upgrading to r2 from r1.5 if using D3D9Ex and frame_delay 0? I don't think I'm using interlaced mode.

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 318
  • Last login:Today at 06:21:27 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #255 on: July 16, 2015, 05:20:25 am »
I've been running some longer tests with framedelay 7, with both a latency of 2 and 1, and they run near flawless, see attached graphs. Given this it looks like the fd8 case must really be a case of pushing it too much, given that the unthrottled speed of the driver is "only" 930%.

It might be worth a shot to increase the ASIO latency to 96/128, and see if it works with fd8. I rebuilt 0.162 with R2 with MSVC, however, genesis actually seems to run slower with MSVC than MinGW. Deathsmiles is still quicker with MSVC though.

Do you think it'd be worth upgrading to r2 from r1.5 if using D3D9Ex and frame_delay 0? I don't think I'm using interlaced mode.

You can revert the old patch by issuing "patch -p1 -E -R < old_patch.txt" and apply the new one with "patch -p1 -E < new_patch.txt" and rebuild to get the new stuff.
« Last Edit: July 16, 2015, 06:08:22 am 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 #256 on: July 16, 2015, 06:41:01 am »
Do you think it'd be worth upgrading to r2 from r1.5 if using D3D9Ex and frame_delay 0? I don't think I'm using interlaced mode.

If you can setup your LCD for 60 Hz (not 120 Hz) it could be interesting to test if the new build still causes static tearing with the new fd patch. If the card is fast enough tearing might disappear (provided you don't use hlsl). This will reduce a frame of latency compared to d3d9ex.
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
  • ***
  • Online Online
  • Posts: 318
  • Last login:Today at 06:21:27 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #257 on: July 16, 2015, 07:10:12 am »
Do you think it'd be worth upgrading to r2 from r1.5 if using D3D9Ex and frame_delay 0? I don't think I'm using interlaced mode.

If you can setup your LCD for 60 Hz (not 120 Hz) it could be interesting to test if the new build still causes static tearing with the new fd patch. If the card is fast enough tearing might disappear (provided you don't use hlsl). This will reduce a frame of latency compared to d3d9ex.

Just tried this with a GeForce GTX 650 Ti BOOST (it certainly is an excellent name), and when run at 640x480 no static tearing can be seen.

The longer it takes to scale (the slower your card is), the lower the tearing will position on the screen. If the tearing is always by the top of the screen, maybe there's a chance to "hide" it effectively by exiting the first synchronization a bit earlier, let's say 32 lines before v-blank:

Code: [Select]
int last_scanline = m_switchres_mode && m_switchres_mode->vtotal?
m_switchres_mode->vactive - 32 + (m_switchres_mode->vtotal - m_switchres_mode->vbegin) / (m_switchres_mode->interlace?2:1) :
m_height - 32;

Obviously the value is system dependent, and may not be consistent. But just for the heck of it. Besides, because we're making the frame time shorter, we also may need to lower the value of fd when using this trick, otherwise we may arrive too late. So this reduces the effectiveness of fd a bit.

Just tried this, and it does hide the tearing when running at higher resolutions. :) The NVIDIA control panel allows virtually any resolution to be added, just tried 1920x480 to allow super-resolution-esque behavior.

It should probably be added as an option, if it's OK with you I'll add it to the next release. I suppose a basic sanity check would be last_scanline > first_scanline?
« Last Edit: July 16, 2015, 07:49:32 am by intealls »

filimpan

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 36
  • Last login:November 28, 2017, 01:54:38 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #258 on: July 16, 2015, 07:53:24 am »
Do you think it'd be worth upgrading to r2 from r1.5 if using D3D9Ex and frame_delay 0? I don't think I'm using interlaced mode.

If you can setup your LCD for 60 Hz (not 120 Hz) it could be interesting to test if the new build still causes static tearing with the new fd patch. If the card is fast enough tearing might disappear (provided you don't use hlsl). This will reduce a frame of latency compared to d3d9ex.

You mean just by setting my monitor to 60Hz without changing anything else, this build would reduce a frame of lag compared to what I'm currently using? I don't really understand. In any case, to my knowledge LCD monitors perform scaling and have other negative effects when run at non-native refresh rates and resolutions. I'd imagine setting the monitor to 60Hz would result in at least one added frame of delay purely because of this.

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 #259 on: July 16, 2015, 09:34:27 am »
It should probably be added as an option, if it's OK with you I'll add it to the next release. I suppose a basic sanity check would be last_scanline > first_scanline?

Correct. Now let's find a suitable name for the option, haha. I'll be adding the new fd code to main GM patch, so maybe this option will be added too.

Still want to figure out a way to make fd value automatic. A good starting point may be controlling the scanline number when we reach the first sync check for each frame. Based on that go increasing fd step by step until we the scanline number overflows over the next frame. The problem is, if emulation time of a frame is variable, we should be capable of allowing some sort of security buffer, which might shrink or grow based on speed stability.
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

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 #260 on: July 16, 2015, 09:38:39 am »
You mean just by setting my monitor to 60Hz without changing anything else, this build would reduce a frame of lag compared to what I'm currently using?

The reason to use 60 Hz is in order to enable fd (which you can't enable now at 120 Hz due to the refresh mismatch). The fd option will remove the extra frame of lag. The reason I'm recommeding you fd *now* is because the new implementation may remove static tearing, oposite to the old one.

Quote
In any case, to my knowledge LCD monitors perform scaling and have other negative effects when run at non-native refresh rates and resolutions. I'd imagine setting the monitor to 60Hz would result in at least one added frame of delay purely because of this.

Scaling should only be triggered by non-native resolutions, rather than refresh rates. However I'm not sure of this.
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

u-man

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 87
  • Last login:November 29, 2023, 05:57:09 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #261 on: July 16, 2015, 10:04:01 am »

In any case, to my knowledge LCD monitors perform scaling and have other negative effects when run at non-native refresh rates and resolutions. I'd imagine setting the monitor to 60Hz would result in at least one added frame of delay purely because of this.

Scaling should only be triggered by non-native resolutions, rather than refresh rates. However I'm not sure of this.
[/quote]

There are no "non-native" refresh rates for LCDs. Either they are supported by the monitor and/or driver or not... simple as that. On the other side, everything else said about resolutions is true, but i still think this would not add lag, it just will looks ---smurfy--- :D .
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."

filimpan

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 36
  • Last login:November 28, 2017, 01:54:38 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #262 on: July 16, 2015, 10:59:02 am »
I read about it a while ago, but it was in a review I read of a 144Hz monitor that I was interested in, probably TFT Central. I lost interest once it was shown that there was immediately something like 10-20ms of extra lag when the monitor was set to 120hz, and progressively more as the refresh rates were lowered. Any refresh rate apart from the default of 144Hz produced a set delay, plus small amounts extra the lower you went. There was also some stuff about backlight strobing. The essence of it was that these LCD monitors produce best results when used at their native refresh rate. I can't find the review now, but you still do see reviews where they recommend higher refresh rates for lower input lag.

Now I understand why you recommended D3D9Ex instead of fd before. Thing is, even with my current build what I notice more than tearing is the game speeding up and down. Framerate benchmark tools show that a 59.583Fps game hitches every few seconds in a predictable pattern to single ~120Fps and 40Fps spikes. The audio noticeably slows down and speeds up for a split second at these intervals.

Anyway, I just tried the new build without D3D9Ex, and with my monitor set to 60Hz, the framerate is stable at 60Fps (so 101% game speed) with frame delay, and no tearing observed. Still the same speedups and slowdowns with 120Hz. My D3D9Ex build doesn't work well with fd whether 120Hz or 60Hz. This makes me wonder if it's possible to get fd working similarly with 120Hz, that way fd can be used with black frame insertion, right?

For now I'm sticking with D3D9Ex with black frame insertion, because I'm not convinced that my monitor running at 60Hz has the same input lag as 120Hz.
« Last Edit: July 16, 2015, 11:01:11 am by filimpan »

u-man

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 87
  • Last login:November 29, 2023, 05:57:09 am
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #263 on: July 16, 2015, 12:36:46 pm »
And you are sure they talked about INPUT-lag in the review of that 144Hz monitor ;) ? Because they mean with "response time" something very different and doesnt have to do with input lag. It doesnt matter that much, for this thread:

http://www.tftcentral.co.uk/speccontent.htm#response%20time
http://www.tftcentral.co.uk/reviews/content/acer_xg270hu.htm#detailed_response
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."

filimpan

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 36
  • Last login:November 28, 2017, 01:54:38 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #264 on: July 16, 2015, 12:40:17 pm »
I'm dead certain it was input lag rather than response time, though I don't know what I'd have to search to find the article again.

Also, I'm having difficulty trying to build with asio_163_r2. I keep getting 1 block failed.

patch -p0 -E < hi_0163.diff
patch -p0 -E < 0163_groovymame_015h.diff
unzip bassasio13.zip in [root dir]\bassasio
go to root dir
patch -p1 -E < asio_163_r2.txt

It's at that stage, 1 out of 3 blocks failed. r1 worked fine...
« Last Edit: July 16, 2015, 01:54:24 pm by filimpan »

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 318
  • Last login:Today at 06:21:27 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #265 on: July 16, 2015, 04:47:21 pm »
I'm dead certain it was input lag rather than response time, though I don't know what I'd have to search to find the article again.

Also, I'm having difficulty trying to build with asio_163_r2. I keep getting 1 block failed.

patch -p0 -E < hi_0163.diff
patch -p0 -E < 0163_groovymame_015h.diff
unzip bassasio13.zip in [root dir]\bassasio
go to root dir
patch -p1 -E < asio_163_r2.txt

It's at that stage, 1 out of 3 blocks failed. r1 worked fine...

Fixed in r2.1, thanks for reporting.

filimpan

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 36
  • Last login:November 28, 2017, 01:54:38 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #266 on: July 16, 2015, 05:33:28 pm »
Ok, haha. I thought it was just me being daft. Thanks  :)

Sorry to harp on about the fd code Calamity, but I finally understood what you were talking about in my thread (my fault). I suppose it now works well with LCD screens since the tearing is gone. Anyway what I want to know is, why doesn't fd work with refresh scaling? Aside from my doubts about monitor performance at lower refresh rates, 120Hz would also be better because it would allow black frame insertion, which as it turns out is a pretty good benefit for LCD screens. If it's a matter of time or work, I'd be happy to help out, though it'd probably be limited to testing since I can't code(? program?). 120Hz+black frame insertion+frame delay would be very neat.
« Last Edit: July 16, 2015, 05:47:15 pm by filimpan »

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 #267 on: July 16, 2015, 06:35:30 pm »
Code: [Select]
60 Hz
 0                     1
 +---------------------+
 +--------- fd 8 -->

120 Hz - refresh scaling
 0          1(0-rep.)  2(1)
 +----------+----------+
 +--------- fd 8 -->

120 Hz - black frame insertion
 0(black)   1(normal)  2(black)
 +----------+----------+
 +--------- fd 8 --> !!

In theory fd should work at 120 Hz provided you use a high enough fd value, in order to jump over the v-sync in the middle. The video card will repeat the previous frame by itself.

However the black frame insertion case is more complicated. If you jump the v-sync in the middle you can't alternate normal/black frames. It should be possible to implement it but not without an important overhaul.
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

filimpan

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 36
  • Last login:November 28, 2017, 01:54:38 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #268 on: July 16, 2015, 07:46:37 pm »
Code: [Select]
60 Hz
 0                     1
 +---------------------+
 +--------- fd 8 -->

120 Hz - refresh scaling
 0          1(0-rep.)  2(1)
 +----------+----------+
 +--------- fd 8 -->

120 Hz - black frame insertion
 0(black)   1(normal)  2(black)
 +----------+----------+
 +--------- fd 8 --> !!

In theory fd should work at 120 Hz provided you use a high enough fd value, in order to jump over the v-sync in the middle. The video card will repeat the previous frame by itself.

However the black frame insertion case is more complicated. If you jump the v-sync in the middle you can't alternate normal/black frames. It should be possible to implement it but not without an important overhaul.

Hmm, I just tried every value of fd from 1 up to 9 (using the non-D3D9Ex r2 build posted above) in 120Hz and still didn't manage to replicate the results gotten at 60Hz. So the same periodic 120Fps and 40Fps jitters, and an average of 100% speed - 59.583Fps, as opposed to the constant 101% speed of 60Fps seen in 60Hz.

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 #269 on: July 17, 2015, 04:41:14 am »
I've been running some longer tests with framedelay 7, with both a latency of 2 and 1, and they run near flawless, see attached graphs. Given this it looks like the fd8 case must really be a case of pushing it too much, given that the unthrottled speed of the driver is "only" 930%.

It might be worth a shot to increase the ASIO latency to 96/128, and see if it works with fd8. I rebuilt 0.162 with R2 with MSVC, however, genesis actually seems to run slower with MSVC than MinGW. Deathsmiles is still quicker with MSVC though.

I tried the different buffer sizes, but it doesn't really make a difference.

I think it's because of the following.

The genesis is running at 60hz, so 16.7ms per frame. Each framedelay unit is 1/10th of this, so 1.67ms. Framedelay 8 is actually framedelay 9 (as previously noted by Calamity), which means that when using frame delay 8 we're actually starting the emulation at 9 x 1.67ms = 15ms into the frame. That only leaves 16.7ms -/- 15ms = 1.7ms for the frame emulation, otherwise it will miss the vertical sync and overflow into the next frame.

Using -bench 60 the genesis emulation runs at 930% for me, or 9.3 times as fast as the real machine. This means MAME emulates a frame in 16.7ms / 9.3 = 1.79ms. As you can see this is taking longer than the 1.70ms available before overflowing. Meaning framedelay 8 simply cannot work stable with a driver that runs at 930%*.

Calamity, could you confirm this in the context of the current framedelay implementation?

If I'm right, my suggestion would be to use this method to calculate a suggested framedelay, and returning this fd value together with the -bench option.  So in my case if I would run "mame genesis -bench 60", it would return not only the average speed 930%, but also return something user friendly like "Based on the average speed, the maximum framedelay value is 7." I think this could help the average user immensely when trying to find/set driver specific framedelay values.   



* That the 1.79ms is so close to the 1.7ms left for emulation, may also explain the erratic behaviour that GMASIO is showing when I'm using framedelay 8 with the genesis driver. Small deviations in speed may allow for it to just work, or not.

« Last Edit: July 17, 2015, 04:43:07 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: GM ASIO PRE-ALPHA
« Reply #270 on: July 17, 2015, 07:54:55 am »
Hmm, I just tried every value of fd from 1 up to 9 (using the non-D3D9Ex r2 build posted above) in 120Hz and still didn't manage to replicate the results gotten at 60Hz. So the same periodic 120Fps and 40Fps jitters, and an average of 100% speed - 59.583Fps, as opposed to the constant 101% speed of 60Fps seen in 60Hz.

Does that happen even if you force -syncrefresh through command line?
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

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 #271 on: July 17, 2015, 07:56:35 am »
Calamity, could you confirm this in the context of the current framedelay implementation?

Absolutely.

Quote
If I'm right, my suggestion would be to use this method to calculate a suggested framedelay, and returning this fd value together with the -bench option.  So in my case if I would run "mame genesis -bench 60", it would return not only the average speed 930%, but also return something user friendly like "Based on the average speed, the maximum framedelay value is 7." I think this could help the average user immensely when trying to find/set driver specific framedelay values.   

Hopefully we can use the scanline number to make this unnecessary, so the user doesn't really need to input any value.
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
  • ***
  • Online Online
  • Posts: 318
  • Last login:Today at 06:21:27 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #272 on: July 17, 2015, 08:23:47 am »
Correct. Now let's find a suitable name for the option, haha. I'll be adding the new fd code to main GM patch, so maybe this option will be added too.

Yeah it's certainly not an easy task to come up with a descriptive name for this option :)

Still want to figure out a way to make fd value automatic. A good starting point may be controlling the scanline number when we reach the first sync check for each frame. Based on that go increasing fd step by step until we the scanline number overflows over the next frame. The problem is, if emulation time of a frame is variable, we should be capable of allowing some sort of security buffer, which might shrink or grow based on speed stability.

Hopefully we can use the scanline number to make this unnecessary, so the user doesn't really need to input any value.

Are you thinking of buffering frames? That would be a neat solution.

In regards to variable emulation time. Deathsmiles for instance seems to vary quite a bit, and might make a nice (if difficult) test case. I've attached a plot of a run with -nothrottle set. As can be seen it varies from about 200% to over 1500% depending on state. (Come to think of it, -asio_log with -nothrottle might also be a fairly easy way to see what fd value the rig is capable of!)

Edit: I think I need to move the logging to RAM and dump the log at emulator exit for more accurate numbers. Might add this to the next release.
« Last Edit: July 17, 2015, 08:57:25 am by intealls »

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 #273 on: July 17, 2015, 09:05:05 am »
If I'm right, my suggestion would be to use this method to calculate a suggested framedelay, and returning this fd value together with the -bench option.  So in my case if I would run "mame genesis -bench 60", it would return not only the average speed 930%, but also return something user friendly like "Based on the average speed, the maximum framedelay value is 7." I think this could help the average user immensely when trying to find/set driver specific framedelay values.   

Hopefully we can use the scanline number to make this unnecessary, so the user doesn't really need to input any value.

Could you lift the veil a little bit of what possible solution with the scanline number you're thinking of? :)

In regards to variable emulation time. Deathsmiles for instance seems to vary quite a bit, and might make a nice (if difficult) test case. I've attached a plot of a run with -nothrottle set. As can be seen it varies from about 200% to over 1500% depending on state. (Come to think of it, -asio_log with -nothrottle might also be a fairly easy way to see what fd value the rig is capable of!)

That is just awesome! Should have thought of that! :)  Much better than the average speed reading of MAME.  There must be a way to spit out a max framedelay value when running -asio_log -nothrottle?


intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 318
  • Last login:Today at 06:21:27 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #274 on: July 17, 2015, 09:08:49 am »
That is just awesome! Should have thought of that! :)  Much better than the average speed reading of MAME.  There must be a way to spit out a max framedelay value when running -asio_log -nothrottle?

Absolutely, I edited the above post to add that I should probably get rid of the log disk writes before we can use it reliably though.

filimpan

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 36
  • Last login:November 28, 2017, 01:54:38 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #275 on: July 17, 2015, 09:12:19 am »
Hmm, I just tried every value of fd from 1 up to 9 (using the non-D3D9Ex r2 build posted above) in 120Hz and still didn't manage to replicate the results gotten at 60Hz. So the same periodic 120Fps and 40Fps jitters, and an average of 100% speed - 59.583Fps, as opposed to the constant 101% speed of 60Fps seen in 60Hz.

Does that happen even if you force -syncrefresh through command line?

:o it works! Praise be. Well, black frame insertion was really growing on me but I think fd is going to take priority for me from now on, so I'm on fd 8 now, and am no longer using D3D9Ex.

Regarding GM ASIO r2, I'm now able to have lower ASIO latency without any over or underruns using the same settings as before (fd 0, black frame insertion 1). Whereas before I was using 288 samples with 0/12 over/under in 3 minutes, I can now use 192 samples with 0/0 over/under for 6 minutes of gameplay. 96 samples results in 0/1. However, I get ~1000 target speed deviations, and this isn't changed when the game is running at 100% (so fd 0 and black frame insertion 0).

I'm now using fd 8, which is having a large impact on overruns and underruns, and I found that buffer had to be raised to 288 again to at least avoid overruns, so I get ~27 underruns in 6 minutes, which isn't very different from what I used to get with fd 0 on r1.5. I hadn't really tested fd before this revision, but I assume that's an improvement.

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 318
  • Last login:Today at 06:21:27 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #276 on: July 17, 2015, 09:16:26 am »
However, I get ~1000 target speed deviations, and this isn't changed when the game is running at 100% (so fd 0 and black frame insertion 0).

You can safely ignore this measurement if you aren't getting any over-/underruns (or very few of them, which you seem to be getting). Are you running with -monitor lcd btw?
« Last Edit: July 17, 2015, 09:18:02 am by intealls »

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 #277 on: July 17, 2015, 09:38:59 am »
That is just awesome! Should have thought of that! :)  Much better than the average speed reading of MAME.  There must be a way to spit out a max framedelay value when running -asio_log -nothrottle?

Absolutely, I edited the above post to add that I should probably get rid of the log disk writes before we can use it reliably though.

This is really great! That would mean no more guessing, or guiding ourself by the average speed %.

I've also ran deathsml, see attached graph. You probably already noticed, but just for other people interested: the low speeds are matched with gameplay, and the high speeds are only achieved during the title screens and such.  So it's not that actual gameplay speed is varying a lot , it's just that the intermediary screens cause the speed to spike every time.

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 318
  • Last login:Today at 06:21:27 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #278 on: July 17, 2015, 09:57:24 am »
That is just awesome! Should have thought of that! :)  Much better than the average speed reading of MAME.  There must be a way to spit out a max framedelay value when running -asio_log -nothrottle?

Absolutely, I edited the above post to add that I should probably get rid of the log disk writes before we can use it reliably though.

This is really great! That would mean no more guessing, or guiding ourself by the average speed %.

I've also ran deathsml, see attached graph. You probably already noticed, but just for other people interested: the low speeds are matched with gameplay, and the high speeds are only achieved during the title screens and such.  So it's not that actual gameplay speed is varying a lot , it's just that the intermediary screens cause the speed to spike every time.

You could also use a RAM disk to get the disk I/O issues pretty much out of the metric.

I've used this one successfully: http://reboot.pro/topic/2148-news/page-4#entry192685

filimpan

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 36
  • Last login:November 28, 2017, 01:54:38 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #279 on: July 17, 2015, 10:52:05 am »
However, I get ~1000 target speed deviations, and this isn't changed when the game is running at 100% (so fd 0 and black frame insertion 0).

You can safely ignore this measurement if you aren't getting any over-/underruns (or very few of them, which you seem to be getting). Are you running with -monitor lcd btw?

Yeah, the amount of underruns I'm getting seems tolerable in practice.

Yup, -monitor lcd. These are the options I've changed from the default in full:

syncrefresh                                 1
sleep                                           0
cheat                                          1
disable_nagscreen_patch           0
disable_loading_patch                0
monitor                                      lcd
frame_delay                                8
lcd_range                                   119-120
asio_cal_freq                              47998.22
multithreading                            1
priority                                        1
« Last Edit: July 17, 2015, 10:56:53 am by filimpan »