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 93966 times)

0 Members and 1 Guest are viewing this topic.

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 #120 on: June 23, 2015, 02:28:46 pm »
Thanks, Calamity.  No worries!  I tested your d3d9ex_flush build briefly yesterday.  Stable 2nd-frame response is what I saw. No next-frame responses without ini files and using d3d/fd9.

I wanted to mention something on the ASIO topic.  Previously I've mentioned that I could use high frame_delay values with ddraw in Neo Geo games with an ASIO latency of 96 and intermediary buffer of 832, but had severe audio problems with CPS1/2/3 games and these settings.  I ran a Neo Geo game without any ini files present and ran into the same issues I do with CPS games.  Normally I use a custom monitor range in a neogeo.ini file since the values switchres gives me by default squishes the picture a bit horizontally.  Adding this custom range back got rid of the audio issues with ddraw and frame_delay 8.  I'd like to do some more testing around this later this week, but wanted to mention it for now.

I suppose I should also mention that I am not using super resolutions in Windows 7.  I've been meaning to get back to trying those out again, and will soon.

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Today at 07:31:32 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #121 on: June 23, 2015, 02:33:51 pm »
I wanted to mention something on the ASIO topic.  Previously I've mentioned that I could use high frame_delay values with ddraw in Neo Geo games with an ASIO latency of 96 and intermediary buffer of 832, but had severe audio problems with CPS1/2/3 games and these settings.  I ran a Neo Geo game without any ini files present and ran into the same issues I do with CPS games.  Normally I use a custom monitor range in a neogeo.ini file since the values switchres gives me by default squishes the picture a bit horizontally.  Adding this custom range back got rid of the audio issues with ddraw and frame_delay 8.  I'd like to do some more testing around this later this week, but wanted to mention it for now.

Thanks again for testing! I just remembered that I've seen something probably similar to this as well, but I could never make sense of it. It's documented in http://forum.arcadecontrols.com/index.php?topic=141869.0 .

This from the first post:
Quote
However, if the game is forced to run at a slightly higher refresh rate, and consequently slightly higher speed, the plot looks like pbobble_custom_fd7.png, which is truly excellent for the ASIO implementation. The crt_range used for this plot is 15625-15750,60.05-60.05,2.000,4.700,8.000,0.064,0.192,1.024,0,0,192,240,0,0.

I'm gonna test this again, and verify that I get next-frame responses when the speed is constant (no spikes).

Edit: And yes, I am able to get next-frame responses when running the game at a slightly higher speed, with no speed spikes, and consequently fewer over-/underruns.

Vicosku: I would be very grateful if you could do a test with the following options (D3D + ASIO with the following build http://www.mediafire.com/download/vztae52cyqgfkch/gmame162_vanilla_asio_no_d3dex.zip), to check over/underrun performance as well as input lag, to verify that you can see the same thing.

Code: [Select]
mame64 -asio_device your_device -asio_cal_freq your_cal_freq -video d3d -frame_delay 7 -monitor custom -crt_range0 15625-15750,59.7-59.7,2.000,4.700,8.000,0.064,0.192,1.024,0,0,192,240,0,0 -v msword
« Last Edit: June 23, 2015, 03:51:54 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 #122 on: June 23, 2015, 04:50:55 pm »
Thank a lot for testing this.

Thanks, Calamity.  No worries!  I tested your d3d9ex_flush build briefly yesterday.  Stable 2nd-frame response is what I saw. No next-frame responses without ini files and using d3d/fd9.

I was afraid of that. It's a shame we can't get next frame response with d3d9ex and no hacks. It was my hope that eventually we could use it to achieve the same consistency we get with ddraw. The problem with ddraw is that it's the lazy confortable solution to just stick with it (as I've done myself for years) but apart from the fact that it doesn't work with W8 (for ATI at least), we need to keep in mind that mamedevs are moving the whole rendering engine to BGFX which does NOT support ddraw and it's expectable that the current rendering modules are dropped altogether when BGFX is finally adopted. DirectDraw is a dead end, but unfortunately newer APIs are still unable to achieve the same low level access whatever they claim. It's frustrating to see how such a simple operation that involved a few lines of code in the assembly days now requires absurdly convoluted constructs and you still fail miserably to get there. And you see how you have a computer with the potential to do something great but it is not possible due to lousy APIs (Linux is no better). You need to resort to hacks, which is bad because it makes it even more difficult to see something like the frame delay feature eventually make into base 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

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 #123 on: June 23, 2015, 05:52:49 pm »
Dr. Venom, I also tried the RadeonPro tool you mentioned.  I used the official .162 build with ddraw and fd9 and used the soft15khz trigger you outlined.  To my surprise, this also produced excellent results, with all but two results showing next-frame response.  Were there other variables you wanted me to test with?

If I understand correctly, before you couldn't get next frame response for the many ddraw cases you tested, apart from 1 that only showed 25% next frame response, and now with the radeon pro flipqueuesize setting to 1 you're getting next frame response almost all of the time? Sound like an -excellent- result indeed!

As such, would you be willing to run the same test for d3d with the d3d9ex builds of Calamity?

Why? My hunch is that SetMaximumFrameLatency in the d3d9ex builds is simply not working (correctly) with this old ATI driver we're using (as I referred to as a possibility earlier). This could be the reason for the disappointing d3d9ex results until now.

If enforcing the FlipQueueSize to 1 indeed will make a difference for these builds, we can probably find out what registry key for the FlipQueueSize is being set by RadeonPro and incorporate this key by default in the CRT emudriver installation!


P.S. Please again make double sure the flipqueuesize is enforced properly, just to make very sure we're getting the correct test results regarding this. (Yes, I'm being fuzzy about this, I know! :) )

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Today at 07:31:32 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #124 on: June 23, 2015, 07:07:38 pm »
After running a couple of tests with the SNES driver (SM Allstars and F-Zero), it appears that forcing the game to run at a slightly higher frequency drastically improves audio performance with frame_delay. On my rig I'm able to use a frame_delay setting of 6 reliably. I've also verified that next-frame input is possible (second frame, the games I tested lag a frame). This has nothing to do with D3Dex, but I figured it could be useful information anyway.

When forcing 60.2 Hz refresh (SNES runs at ~60.1 Hz), performance is beautiful. When using generic_15, sample generation seems to go haywire after a few seconds, as seen in the plots attached.

I ran with the following switches (vanilla + ASIO)

Code: [Select]
mame64 -asio_log -asio_device 1 -asio_cal_freq 48001.52 -video d3d -frame_delay 6 -monitor custom -crt_range0 15625-15750,60.2-60.2,2.000,4.700,8.000,0.064,0.192,1.024,0,0,192,240,0,0 -v snes > gm_custom.log

Edit: I think what's causing it is the intermittent delay problem outlined in this post: http://forum.arcadecontrols.com/index.php/topic,142143.msg1484914.html#msg1484914
« Last Edit: June 23, 2015, 08:34:06 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 #125 on: June 23, 2015, 09:13:52 pm »
Calamity, I agree, it's frustrating.  I'm already very happy with GroovyMAME as it is, but when perfection is dangling just out of reach, it's hard not to want more.  It's too bad the APIs are making things so difficult.

As such, would you be willing to run the same test for d3d with the d3d9ex builds of Calamity?

I had the same thought!  I ran tests again with frame_delay 6 and 9 and the RadeonPro tool.  Unfortunately, I still only get 2nd frame response.  What would be the best way to verify that RadeonPro is working as desired, and provide evidence of it in this thread?  It and soft15khz are open and I believe the settings are in effect, but I also want to be sure about this.

it appears that forcing the game to run at a slightly higher frequency drastically improves audio performance with frame_delay.

Very interesting!  I'll have to play with this.

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Today at 07:31:32 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #126 on: June 24, 2015, 11:09:44 am »
it appears that forcing the game to run at a slightly higher frequency drastically improves audio performance with frame_delay.

Very interesting!  I'll have to play with this.

Also, please try the Octave script. It helps you understand if the over-/underruns are due to fluctuating game speed, or other factors. The game speed in sfiii for instance seems to drop when changing screens (player select -> fight etc), which will lead to buffer problems. Also, please note that the -asio_log option writes to disk, which can affect the results. I use an SSD in my test rig, to minimize problems like this (I really should place this in memory, and dump the log at emulator exit).

After a bit of tweaking, I can run sfa3/sf2hf with frame_delay 7/d3d with zero issues if the games are forced to run at 59.7 Hz on my i3-4130.

I can also run pbobble with zero issues at frame_delay 8/d3d, if forcing the game to run at 60.05 Hz.
« Last Edit: June 24, 2015, 11:26:32 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 #127 on: June 24, 2015, 11:18:21 am »
Will do.  I use an SSD as well.  Would you mind sharing the range you use to run SFA3 at 59.7 Hz?  My memory is a bit fuzzy on setting these up, so if you have settings that already work well, I'd love to use them and save some time.  Thanks!

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Today at 07:31:32 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #128 on: June 24, 2015, 11:28:10 am »
Will do.  I use an SSD as well.  Would you mind sharing the range you use to run SFA3 at 59.7 Hz?  My memory is a bit fuzzy on setting these up, so if you have settings that already work well, I'd love to use them and save some time.  Thanks!

The switch(es) I use are -monitor custom -crt_range0 15625-15750,59.7-59.7,2.000,4.700,8.000,0.064,0.192,1.024,0,0,192,240,0,0

Which is generic_15 with a forced refresh.

The entire command used is

Code: [Select]
mame64 -video d3d -nosleep -priority 1 -nodisable_nagscreen_patch -nodisable_loading_patch -asio_log -v -asio_device 1 -asio_cal_freq 48001.651 -frame_delay 7 -monitor custom -crt_range0 15625-15750,59.7-59.7,2.000,4.700,8.000,0.064,0.192,1.024,0,0,192,240,0,0 -v sfa3  1>gm_custom.log
« Last Edit: June 24, 2015, 11:30:59 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 #129 on: June 24, 2015, 11:29:16 am »
After a bit of tweaking, I can run sfa3/sf2hf with frame_delay 7/d3d with zero issues if the games are forced to run at 59.7 Hz on my i3-4130.

I can also run pbobble with zero issues at frame_delay 8/d3d, if forcing the game to run at 60.05 Hz.

Just wondering... is the theoretical modeline refresh used at any point in your code? I mean, could your code be taking that value for granted even if it's only an approximation? I can't see a possible relation between increasing the speed and more stable results, other than accidentaly obtaining a more accurate refresh rate (accurate with respect to the estimated value, not to the game's refresh I mean).
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:Today at 07:31:32 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #130 on: June 24, 2015, 11:33:53 am »
Just wondering... is the theoretical modeline refresh used at any point in your code? I mean, could your code be taking that value for granted even if it's only an approximation? I can't see a possible relation between increasing the speed and more stable results, other than accidentaly obtaining a more accurate refresh rate (accurate with respect to the estimated value, not to the game's refresh I mean).

Nope, the only value that's used is the game speed (speed_percent).

The relationship is

Code: [Select]
BASS_ASIO_ChannelSetRate(0, i, ((double) m_machine->sample_rate() + (double) m_asio_rate - (double) m_asio_rate_compensated) * (double) m_machine->video().speed_percent());

Basically, 48000 * speed_percent, if ignoring the correction factor (m_asio_rate_compensated).

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Today at 07:31:32 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #131 on: June 24, 2015, 11:37:10 am »
Right now, I think there's two main factors that's causing ASIO problems with frame_delay.

The first one is the 'speed spikes' outlined in the GroovyMAME speed questions thread. I couldn't reproduce this on my second rig (C2D 2.95 GHz).

The other is the intermittent sample delay problem, mentioned a few posts up.

Both seem to be able to be mitigated by running the game at a slightly higher speed, for some reason.

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 #132 on: June 24, 2015, 11:52:54 am »
If the speed is a determining factor, I'd try the following. Run GM with the -speed option, reflecting the actual modeline_refresh/game_refresh ratio. E.g.:

groovymame sfa3 -monitor generic_15 -fd 7 -speed 0.997

(in case the modeline generated by generic_15 produces a 99.7% speed)

This is an attempt to compensate for the refresh difference. GM does this internally *unless* the frame_delay option is used.
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:Today at 07:31:32 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #133 on: June 24, 2015, 12:25:46 pm »
If the speed is a determining factor, I'd try the following. Run GM with the -speed option, reflecting the actual modeline_refresh/game_refresh ratio. E.g.:

groovymame sfa3 -monitor generic_15 -fd 7 -speed 0.997

(in case the modeline generated by generic_15 produces a 99.7% speed)

This is an attempt to compensate for the refresh difference. GM does this internally *unless* the frame_delay option is used.

Ok, thanks! Should the -speed quote reflect the actual refresh rate produced (measured with oscilloscope), or the one generated with the modeline?

Edit: clarification(s).

Also, will this change be reflected in speed_percent? I just ran sf2 for a while and got a speed of 100.13%. When restarting with -speed 1.0013, the buffer underruns continuously.
« Last Edit: June 24, 2015, 12:28:37 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 #134 on: June 24, 2015, 12:44:47 pm »
I'd say it should reflect the actual measured speed, not the one resulting from the modeline numbers because the dotclock is only approximate.

If you're going to use the value from MAME do it after running without -fd (-syncrefresh only).

If you use -speed 1.2 the speed_percent should be 120%, yes.

You can also take the modeline from GM and try it in Arcade OSD to measure the refresh.

Just to clarify my reasoning (which will probably be wrong): if using a mode that forces the game to run faster works, maybe telling the game it must run slower than the modeline also works, because it will end up running faster than it's trying to.
« Last Edit: June 24, 2015, 12:50:59 pm by Calamity »
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:Today at 07:31:32 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #135 on: June 24, 2015, 02:38:49 pm »
I measured the VSYNC lead when running sf2 to 59.625 Hz, the game is running at 59.637 Hz, so this gives a -speed quote of 0.9998. Unfortunately, the speed spikes still appear.

However, interesting things happened in regards to the other problem.

I measured SNES to an actual 60.043, and it runs at 60.098. When run with -speed 0.9991 (and FD 6 with D3D), I can't reproduce the intermittent delay problem.

I attached two plots which show that delays are gone when running with the correct speed, and present when not.

Edit: Just tried another game (gunforce), without correct speed: delays, with: no delays! You're the man! :) Do you have any theory about what could be causing this, and will this affect frame_delay in some way?
« Last Edit: June 24, 2015, 02:46:06 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 #136 on: June 24, 2015, 02:41:50 pm »
I've been testing a new mod. This is for plain D3D9. In drawd3d.c, just replace this function:

Code: [Select]
void renderer::end_frame()
{
window().m_primlist->release_lock();

// flush any pending polygons
primitive_flush_pending();

m_shaders->end_frame();

// finish the scene
HRESULT result = (*d3dintf->device.end_scene)(m_device);
if (result != D3D_OK) osd_printf_verbose("Direct3D: Error %08X during device end_scene call\n", (int)result);

// 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));

osd_printf_verbose("\nwait vblank start\n");
while (!raster_status.InVBlank)
{
if ((*d3dintf->device.get_raster_status)(m_device, &raster_status) != D3D_OK)
break;

osd_printf_verbose("current_line: %d\n", raster_status.ScanLine);
if (raster_status.ScanLine >= m_height)
break;
}
}

// present the current buffers
result = (*d3dintf->device.present)(m_device, NULL, NULL, NULL, NULL, 0);
if (result != D3D_OK) osd_printf_verbose("Direct3D: Error %08X during device present call\n", (int)result);

// 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));

osd_printf_verbose("wait vblank end\n");
while (!raster_status.InVBlank)
{
if ((*d3dintf->device.get_raster_status)(m_device, &raster_status) != D3D_OK)
break;

osd_printf_verbose("current_line: %d\n", raster_status.ScanLine);
}
}
}

The system I've been testing this is an i7-4771 3.5GHz, Radeon R9 270, LCD monitor. I don't know how this will behave with older cards/drivers. Here I've been amazed that it can log several hits per scanline. This opens a new horizon of custom vertical synchronization. Beware of the size of the logs if you run this build too long.

Ideally this build should be very stable even with frame_delay. I don't know how good or bad it will behave with asio (hopefully better than current implementation).

The value m_height here:
Code: [Select]
if (raster_status.ScanLine >= m_height)
is the total height of the screen, however usually we will use a somewhat lower value (substract some lines) to account for the time it takes the card to render the frame in paralell, so that when it finishes rendering it actually hits vblank. This way I expect to remove static tearing for LCDs too, although a pretty decent video card will be required. The dynamic estimation of how many lines to substract there is a challange.

There's something critical I've found out: the frame_delay value is off by 1 unit of what's supposed to be. So if you use -frame_delay 8, it's effect is -frame_delay 9. If you use -frame_delay 9, it actually "wraps" to the next frame, so -fd 9 must not be used!
« Last Edit: June 24, 2015, 02:44:25 pm by Calamity »
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 #137 on: June 24, 2015, 03:17:52 pm »
I had the same thought!  I ran tests again with frame_delay 6 and 9 and the RadeonPro tool.  Unfortunately, I still only get 2nd frame response.  What would be the best way to verify that RadeonPro is working as desired, and provide evidence of it in this thread?  It and soft15khz are open and I believe the settings are in effect, but I also want to be sure about this.

Thanks for testing, it's a bummer it doesn't appear to do anything for d3d but that's the way it is...  The best way to verify that it's invoked is by what I outlined earlier, i.e. you should start with Aero/glass desktop enabled, and then when you start the soft15khz.exe you should see aero/glass turning off, confirming that its triggering the radeon pro profile. But I'm sure you did this already, per my earlier post.

There's something critical I've found out: the frame_delay value is off by 1 unit of what's supposed to be. So if you use -frame_delay 8, it's effect is -frame_delay 9. If you use -frame_delay 9, it actually "wraps" to the next frame, so -fd 9 must not be used!

Thanks for letting us know. This then finally confirms and explains my earlier experiences with that high a frame delay value. I always blamed PC/videocard microstutter for the problems with the timing being too tight at fd 9. But this makes much more sense.

With regards to the topic of video rate and audio timing.

Toni Wilen of WinUAE implemented a short loop using GetRasterStatus to quickly measure the actual monitor refresh on emulator startup. If I remember correctly he uses about 50 frames / 1 second of startup time for this and then accordingly adjusts the emulation / audio speed.  It's remarkably accurate, so it seems measuring the monitor refresh rate doesn't need the long calibration that we're used to with soundcards.

Would this be helpful for GM and ASIO synchronisation?

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 #138 on: June 24, 2015, 03:40:00 pm »
The value m_height here:
Code: [Select]
if (raster_status.ScanLine >= m_height)
is the total height of the screen, however usually we will use a somewhat lower value (substract some lines) to account for the time it takes the card to render the frame in paralell, so that when it finishes rendering it actually hits vblank. This way I expect to remove static tearing for LCDs too, although a pretty decent video card will be required. The dynamic estimation of how many lines to substract there is a challange.

This is actually how Toni Wilen has implemented it for WinUAE. I don't think a dynamic estimation is possible, such that it pleases everyone. In WinUAE the value can be changed manually through the configuration file for individual problem (tearing) cases.

This reminds me, with regards to audio synchronization, he ended up chopping each frame into three parts (which you can do as you reliably read the scanline height), and feeding the audio buffer three times per frame. For WinUAE this resulted in pretty stable audio even for ASIO and WASAPI.  The drawback however is that a framedelay feature then isn't possible anymore...


Edit: sorry for posting back to back, I should have edited my previous post.

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 #139 on: June 24, 2015, 03:52:07 pm »
Do you have any theory about what could be causing this, and will this affect frame_delay in some way?

My understanding is:

The -speed option, internally is speed_factor(), and is applied to the sound final mix. In src/emu/sound.c, sound_manager::update,

Code: [Select]
UINT32 finalmix_step = machine().video().speed_factor();
That way you can correct the speed mismatch manually.

In GM what we do is to dynamically compute that speed factor (m_speed) from the computed speed percentage, this way the emulated speed and the actual refresh quickly converge causing audio to be synchronized with video. In src/emu/video.c, video_manager::recompute_speed

Code: [Select]
if (m_syncrefresh && m_throttled && m_framedelay == 0)
m_speed = m_speed_percent * 1000;

The nice thing about this is that we don't need to calculate the actual refresh in order to dynamically sync audio and video (compare this to the pompous Dynamic Rate Control that requires the monitor refresh value as user input).

The problem as you see above is the synchronization is not performed while frame_delay is on. This was done because when developing frame delay we found that the speed percentage was not reliable enough, so using it as feedback caused the speed to diverge dramatically after a few iterations. This was what we found at the time, maybe things are different now with faster CPUs, I haven't tested since then.
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 #140 on: June 24, 2015, 04:06:06 pm »
I measured SNES to an actual 60.043, and it runs at 60.098. When run with -speed 0.9991 (and FD 6 with D3D), I can't reproduce the intermittent delay problem.

Calamity, how many frames do you estimate it would take to on the fly measure the real refresh rate after a video mode change? If it could be done very quickly (a few frames), and have sufficient accuracy, the -speed option could be fed internally.

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 #141 on: June 24, 2015, 04:10:45 pm »
This is actually how Toni Wilen has implemented it for WinUAE. I don't think a dynamic estimation is possible, such that it pleases everyone. In WinUAE the value can be changed manually through the configuration file for individual problem (tearing) cases.

This reminds me, with regards to audio synchronization, he ended up chopping each frame into three parts (which you can do as you reliably read the scanline height), and feeding the audio buffer three times per frame. For WinUAE this resulted in pretty stable audio even for ASIO and WASAPI.  The drawback however is that a framedelay feature then isn't possible anymore...

 :) Makes me feel I'm reinventing the wheel, but definitely WinUAE is a very good wheel.

The thing is, last time I tested GetRasterstatus I couldn't get anything even close to a hit per scanline, it's performance was waaaaay worse. Now I'm wondering... because when you log to the console you get very few hits as compared to logging to a file, so maybe this is what happened last time. Or maybe it's just that the hardware I'm testing now is much better.

I don't think either that dynamic estimation is possible. I've noticed that not every card brand does the same. The intel in my laptop reports 768 (1366x768) as it last scanline. The R9 270 on the other hand keeps reporting lines after 1600, so it actually reports the blanking lines as normal lines and only reports in vblank state when reaching line 0.

But anyway having reliable access to the current scanline number actually makes a world of a difference. For instance, when using frame_delay 8 I noticed that the first scanline reported after the actual frame_delay wait period was always very close to 1440. 1440/1600 = 0.9. When using frame_delay 7, it was around 1280 (0.8 ).

Using that information, maybe, it should be possible to deduce the proper max value for frame_delay, automatically.
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 #142 on: June 24, 2015, 04:16:24 pm »
Calamity, how many frames do you estimate it would take to on the fly measure the real refresh rate after a video mode change? If it could be done very quickly (a few frames), and have sufficient accuracy, the -speed option could be fed internally.

The speed option is already fed internally (when not using frame_delay), as I explained. Measuring the refresh rate accurately takes lot of time (I use 6 to 9 seconds in Arcade OSD). However, feeding the emulation speed with the speed percentage, *provided you have a reliable vsync*, converges much faster and you can do it as you go.
« Last Edit: June 24, 2015, 04:18:31 pm by Calamity »
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:Today at 07:31:32 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #143 on: June 24, 2015, 04:47:12 pm »
Calamity, how many frames do you estimate it would take to on the fly measure the real refresh rate after a video mode change? If it could be done very quickly (a few frames), and have sufficient accuracy, the -speed option could be fed internally.

The speed option is already fed internally (when not using frame_delay), as I explained. Measuring the refresh rate accurately takes lot of time (I use 6 to 9 seconds in Arcade OSD). However, feeding the emulation speed with the speed percentage, *provided you have a reliable vsync*, converges much faster and you can do it as you go.

Hmm. I see why you disable m_speed = m_speed_percent * 1000 when using frame_delay, the speed oscillates between 1.0 -> 1.4 when enabled. What I don't get is how I'm able to use speed_percent reliably with the ASIO stuff.

Code: [Select]
if (m_syncrefresh && m_throttled && m_framedelay == 0)
m_speed = m_speed_percent * 1000;

The nice thing about this is that we don't need to calculate the actual refresh in order to dynamically sync audio and video (compare this to the pompous Dynamic Rate Control that requires the monitor refresh value as user input).

The problem as you see above is the synchronization is not performed while frame_delay is on. This was done because when developing frame delay we found that the speed percentage was not reliable enough, so using it as feedback caused the speed to diverge dramatically after a few iterations. This was what we found at the time, maybe things are different now with faster CPUs, I haven't tested since then.

Actually, the ASIO patch disables this (as per a previous tip from you :) ), and uses speed_percent along with the calibration frequency to resample the audio, so m_speed is always 1000.

Basically, ASIO wants samples to come in regularly in a fixed interval, if samples stop coming in regularly, underruns occur, this is what could happen in the above SNES examples, with the intermediary delays (mitigated by an increased buffer size).

With the speed spikes, a bunch of samples are delivered at once. This is no good, and will lead to overruns.

If the game speed, monitor refresh rate as well as the ASIO output frequency are known, all is well, as long as the samples keep coming in at the fixed interval.

Toni Wilen of WinUAE implemented a short loop using GetRasterStatus to quickly measure the actual monitor refresh on emulator startup. If I remember correctly he uses about 50 frames / 1 second of startup time for this and then accordingly adjusts the emulation / audio speed.  It's remarkably accurate, so it seems measuring the monitor refresh rate doesn't need the long calibration that we're used to with soundcards.

Would this be helpful for GM and ASIO synchronisation?

I'd love to try this out, do you have a link to the relevant source?

Edit:

Hmmmm. m_speed is always 1000 with ASIO, but when running with the -speed option, it sets m_speed as per

Code: [Select]
m_speed(original_speed_setting())
« Last Edit: June 24, 2015, 05:20:37 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 #144 on: June 24, 2015, 05:22:41 pm »
Hmm. I see why you disable m_speed = m_speed_percent * 1000 when using frame_delay, the speed oscillates between 1.0 -> 1.4 when enabled. What I don't get is how I'm able to use speed_percent reliably with the ASIO stuff.

The patch I posted today: the idea is to get a reliable speed percentage with frame delay enabled. This was the aim of the D3D9Ex build too but unfortunately it leads to 1 frame of lag. Basically we want to mimic ddraw. Once we have a reliable speed percentage we can use it to feed m_speed again.
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 #145 on: June 24, 2015, 05:57:26 pm »
I don't think either that dynamic estimation is possible. I've noticed that not every card brand does the same. The intel in my laptop reports 768 (1366x768) as it last scanline. The R9 270 on the other hand keeps reporting lines after 1600, so it actually reports the blanking lines as normal lines and only reports in vblank state when reaching line 0.

Indeed. I guess this may be a "feature" of newer LCD's, they may have fake blanking periods (for historical compatability reasons), so possibly all you get back is the line that was set as being "start of vblank" by the manufacturer. For CRT's this shouldn't be a problem though. 

Quote
But anyway having reliable access to the current scanline number actually makes a world of a difference. For instance, when using frame_delay 8 I noticed that the first scanline reported after the actual frame_delay wait period was always very close to 1440. 1440/1600 = 0.9. When using frame_delay 7, it was around 1280 (0.8 ).

Way cool man, that you found out like this :)

Quote
Using that information, maybe, it should be possible to deduce the proper max value for frame_delay, automatically.

Maybe, indeed. The variation in the time it takes MAME to render different frames will probably remain an obstacle for automating this though. You don't want frame skipping during the process of deducing the maximum reliable framedelay value.

The speed option is already fed internally (when not using frame_delay), as I explained. Measuring the refresh rate accurately takes lot of time (I use 6 to 9 seconds in Arcade OSD). However, feeding the emulation speed with the speed percentage, *provided you have a reliable vsync*, converges much faster and you can do it as you go.

I was mainly referring to Intealls quote on his SNES test case, so I meant feeding a speed percentage when using framedelay.  Of course the automated process of how it's done without framedelay is much better. But in this case we're trying to tackle the case with framedelay.

Could you possibly run a test, what kind of refresh rate value reliability you could get by only using a measurement of 30 or 60 frames?

I remember when logging WinUAE's output in "low latency vsync" mode, it almost immediately reported the new refresh rate after a screenmode change and it was quite accurate too for my CRTs. Possibly now we can do with a shorter test interval than you're using for Arcade OSD, just as long as it is "accurate enough" for feeding back a better speedpercentage when using framedelay?**

Toni Wilen of WinUAE implemented a short loop using GetRasterStatus to quickly measure the actual monitor refresh on emulator startup. If I remember correctly he uses about 50 frames / 1 second of startup time for this and then accordingly adjusts the emulation / audio speed.  It's remarkably accurate, so it seems measuring the monitor refresh rate doesn't need the long calibration that we're used to with soundcards.

Would this be helpful for GM and ASIO synchronisation?

I'd love to try this out, do you have a link to the relevant source?

Unfortunately I don't have a direct link to the relevant source, sorry. I only know through the discussions we had on the topic. But in case it's of any help, his GitHUB can be found overhere: https://github.com/tonioni/WinUAE.

** Edit: Ah, I think I understand you better know, you're already looking for a way to reimplement feeding the correct speed percentage when using framedelay. Of course if that would work, it would be a charming solution. Possibly also more charming as refresh rates of CRT's may vary a tiny bit when they heat up, which would be taken into account as you're calculating the speed percentage constantly as you go...
 
« Last Edit: June 24, 2015, 06:25:22 pm by Dr.Venom »

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Today at 07:31:32 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #146 on: June 24, 2015, 06:39:40 pm »
Hmm. I see why you disable m_speed = m_speed_percent * 1000 when using frame_delay, the speed oscillates between 1.0 -> 1.4 when enabled. What I don't get is how I'm able to use speed_percent reliably with the ASIO stuff.

The patch I posted today: the idea is to get a reliable speed percentage with frame delay enabled. This was the aim of the D3D9Ex build too but unfortunately it leads to 1 frame of lag. Basically we want to mimic ddraw. Once we have a reliable speed percentage we can use it to feed m_speed again.

Gotcha. I just tried it out, and guess what? No speed spikes in msword/sf2!

You wanna know something else? No intermittent delay problem in SNES!

Thanks alot for the patch, this seems to address the two most frequent problems I've seen.

One issue however :) It seems that sometimes, the game speed is incorrectly set at startup, and locks in at about 116->150%. Restarting a couple of times seems to get it 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 #147 on: June 25, 2015, 09:34:19 am »
These are great news!

That's the problem I was concerned about. Maybe we could add some safe limits to m_speed_percent and only apply it if we're within those limits.

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

stellarola

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 644
  • Last login:June 24, 2020, 11:46:59 pm
  • .::For the love of the game::.
Re: GM ASIO PRE-ALPHA
« Reply #148 on: June 25, 2015, 11:20:00 am »
These are great news!

That's the problem I was concerned about. Maybe we could add some safe limits to m_speed_percent and only apply it if we're within those limits.

This is getting really interesting...   :cheers:
« Last Edit: June 25, 2015, 11:34:51 am by stellarola »

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Today at 07:31:32 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #149 on: June 25, 2015, 04:16:01 pm »
These are great news!

That's the problem I was concerned about. Maybe we could add some safe limits to m_speed_percent and only apply it if we're within those limits.

Testing now, and it looks promising. Currently it's adjusted if the new speed is 100% +- 3%. It's probably going to be a couple of days before another release, lots of stuff that needs doing the next few days.

Also, thanks again for your help, it certainly speeds things up. :)

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 #150 on: June 25, 2015, 04:39:14 pm »
Great news guys, it's awesome that gm is getting so close to realtime performance.

Looking forward to testing the next release!

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 #151 on: June 25, 2015, 05:05:34 pm »
Looking forward to testing the next release!

Same here!  Exciting stuff!

cools

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 645
  • Last login:March 11, 2024, 02:59:06 pm
  • Arcade Otaku Sysadmin
    • Arcade Otaku
Re: GM ASIO PRE-ALPHA
« Reply #152 on: June 26, 2015, 09:23:23 am »
Using that information, maybe, it should be possible to deduce the proper max value for frame_delay, automatically.

 :cheers: :applaud: :burgerking:

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 498
  • Last login:June 12, 2023, 09:19:49 am
  • Z80 ERROR
Re: GM ASIO PRE-ALPHA
« Reply #153 on: June 26, 2015, 09:33:41 am »

Indeed, very exciting news here. Great hope to see a concept/proof in next release ;-)

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Today at 07:31:32 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #154 on: June 26, 2015, 11:34:16 am »
Great hope to see a concept/proof in next release ;-)

With that kind of attitude, there's always the unfortunate risk you're not going to get to see anything at all. ;-)

Currently, the ASIO patch is still PRE-ALPHA. A PRE-ALPHA is bound to have issues, and the nature of a PRE-ALPHA is that it is experimental. Frame delay is an experimental feature. When combining two experimental features, weird and exotic problems are bound to arise. Even though the two most common problems I've seen currently do seem to be addressed, this certainly does not mean no other issues will arise.

Also, it's still very much up to the user to have a proper calibration frequency (might bump to ALPHA when this is no longer needed), and to make sure that the PC that's running the game is capable of running it at the specified frame_delay. So, to re-iterate, even though the two most common issues seem to be sorted, I'd say it's pretty damn hard to prove that all will be working perfectly henceforth, and that no other issues will be uncovered.

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 #155 on: June 26, 2015, 01:10:11 pm »
The last patch I posted is not exactly right from what I've been seeing these days. Now that I've seen with more attention how the scanlines are numbered, it's really interesting, this weekend I'll try a better implementation.

I also noticed that the other patch I posted several days ago (fd_flush for D3D9Ex) would never had worked due to a very silly error (you'll spot it for sure). Anyway I'm not so much interested about D3D9Ex any more.

Quote
When combining two experimental features, weird and exotic problems are bound to arise.

Quite true.
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

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 498
  • Last login:June 12, 2023, 09:19:49 am
  • Z80 ERROR
Re: GM ASIO PRE-ALPHA
« Reply #156 on: June 27, 2015, 04:04:20 am »
I can only agree to what has been said. Nevertheless, I salute the effort and I am not worried about the development cycle which always lead to bug discoveries, strange behaviours and long nights debugging (with beers) ;-)

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 #157 on: June 27, 2015, 02:37:32 pm »
Intealls,

Until the next release is out, could you possibly test the game Mega Turrican in the genesis driver?

This may be a(nother) nice testcase for the ASIO release, as this game switches back and forth between 320x224 and 256x224 screenmodes during the intro, title screen and in-game and the previous ASIO release has some very pronounced issues (pitch changes) with this. So basicly when you press fire during the intro, upon the switch to the title screen there's pitch change. And then when you press start, upon entering the game there again a short pitch change. Just curious whether the current build improves on this or not. 

Of course we can always use a super resolution (like e.g. 1280x0 for genesis), to prevent the physical screenmode switching if this proves to be a permanent issue. But as said, just to provide another test case :)

Could you possibly explain a bit what the log value in the line "ASIO: Average callback timeslice usage" means, and how it is likely to impact emulation performance? 
« Last Edit: June 27, 2015, 02:39:09 pm by Dr.Venom »

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Today at 07:31:32 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #158 on: June 27, 2015, 05:09:09 pm »
Intealls,

Until the next release is out, could you possibly test the game Mega Turrican in the genesis driver?

This may be a(nother) nice testcase for the ASIO release, as this game switches back and forth between 320x224 and 256x224 screenmodes during the intro, title screen and in-game and the previous ASIO release has some very pronounced issues (pitch changes) with this. So basicly when you press fire during the intro, upon the switch to the title screen there's pitch change. And then when you press start, upon entering the game there again a short pitch change. Just curious whether the current build improves on this or not. 

Of course we can always use a super resolution (like e.g. 1280x0 for genesis), to prevent the physical screenmode switching if this proves to be a permanent issue. But as said, just to provide another test case :)

Could you possibly explain a bit what the log value in the line "ASIO: Average callback timeslice usage" means, and how it is likely to impact emulation performance?

Absolutely, I've been trying genesis a bit, and it provides a good test case just as you say. I'm currently doing quite a few changes, which I hope will give a better experience for games with varying speeds. I'm also going to look into the sync disparity issue, and see if that can be mitigated to a reasonable extent.

I'm currently running semi-continuous batch tests of the following games. I'm gonna add Mega Turrican to that list.

Code: [Select]
FD 8 = garouh sf2hf pbobble neodrift gunforce samsho4 mk2
FD 7 = donpachi sfiii3n pbobble2 rfjet

The callback timeslice usage will not affect emulation performance, I put it there just to get an idea of how fast a CPU is actually needed for ASIO to work properly. If it's above 1.0, the callback routine is too slow, it'll also likely increase if using smaller ASIO buffers. But for any decently fast CPU it could probably be safely ignored.

Edit: Hmm. Genesis is gonna be difficult to get to sound good :) It's still a good test case - however, possibly the most difficult one, since samples pretty much stop coming in after a resolution switch. No proper solution apart from increasing the latency (a lot) is going to be possible, I tried experimenting with muting the audio after the switch, but this isn't exactly proper. I think you're going to have to stick to super resolutions for the time being.
« Last Edit: June 27, 2015, 09:39:13 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 #159 on: June 28, 2015, 02:44:19 pm »
Thanks for testing this and trying some alternatives to get it to work. It's indeed one of the harder testcases. Running it with a very large audiobuffer would defy the whole purpose of ASIO, so that isn't an option. Adding hackish workarounds for it wouldn't be right either as you say, I agree. Luckily we have super resolutions, so I'll stick with those for these kind of systems/drivers.

Getting back to the topic of audio latency and framedelay, another thought popped into my mind. Hopefully one of you has an idea about the following.

When adding Framedelay 8, we're "postponing" the sample generation and copy to audio buffer by almost a full frame.

I'm not an expert on the old systems from the 70's and 80's, but I imagine most (8-bit and 16-bit) systems work with extremely tight buffers, such that say after (max?) 1 ms into the first frame the audio already starts playing? (Hypothesis)

Now compare this to our emulated case, with framedelay 8, at earliest audio can begin playing at the end of the first frame. In effect we will -always- have a minimum of approximately one frame of audio delay when we are using framedelay of 8, compared to the real thing, regardless of how tight the audio buffer in the emulation is.

This made me reconsider whether we can have both input latency and audio latency close to realtime, or that it's a case of either:
- audio close to realtime but input latency of about a frame (no framedelay)
- input latency close to realtime but audio latency of about a frame at minimum (high value of framedelay)

I guess the crucial question is: how fast do most of the (arcade) systems that were introduced in the 70's and 80's start playing audio, measured from the very start of the first frame?

Hope this makes sense.


« Last Edit: June 28, 2015, 02:45:52 pm by Dr.Venom »