GM ASIO ALPHA 0.171

[intealls]

Notice: This is deprecated. Use the native PortAudio feature instead.

This alternative GM build uses BASSASIO (www.un4seen.com), which in turn uses ASIO to provide lower audio latency. At best, a reduction of around 75 milliseconds can be achieved (compared to dsound with -audio_latency 1.0, see http://forum.arcadecontrols.com/index.php/topic,141869.msg1469093.html#msg1469093).

Should work on both XP and Windows 7/8/10. Note that for XP you really need a proper ASIO-capable card for decent performance.

Steps to getting things running:

Sound card with native ASIO driver:
* Configure the latency through its control panel and run the executable, you could also use batool(64) to access the control panel.

No native ASIO driver:
* Install ASIO4ALL (http://asio4all.com/) and check 'Use off-line settings' during the installation
* Start GM with -window. In the tray, a green ASIO4ALL icon should show up. Click this and configure the sound card to be used. The settings pane should look something like the attachment (make sure to enable 'Pull mode'!). I've gotten the best results with integrated cards. The result with discrete cards range from excellent to terrible. Try setting a latency of 96, and restart GM to try it out. If the sound is crackling continuously, with a game you know should run well (for instance pbobble), try a higher setting.
* If you're not pleased with the latency you can achieve with ASIO4ALL (you should be pleased with anything lower or equal to 256), buy an old SB Live!/Audigy and use that with the kX driver. See the _kX section in http://forum.arcadecontrols.com/index.php/topic,141869.msg1469502.html#msg1469502 for more info.

If you encounter problems, post here, and I will do my best to help out.

Required settings for CRT Emudriver:

Code: [Select]

multithreading            1

Required settings for 60hz LCD:

Code: [Select]

monitor                   lcd
refresh_dont_care         1
multithreading            1

Required settings for 120hz LCD:

Code: [Select]

monitor                   lcd
multithreading            1

Known problems:
Games running at very inconsistent speeds will probably sound worse than with the other APIs. HyperSpin with ASIO4ALL+Realtek does not work properly.

Build instructions:
See this post for build instructions

Frame delay benchmark:
* A frame delay benchmark is added. Simply use -bench [seconds] and check the log to see the percentage of frame times with the given frame delay. To use the traditional benchmark behavior use -bench [seconds] -video none -sound none.
Example:

Code: [Select]

mame64 samsho4 -bench 180 on my computer outputs
...
Frame delay/percentage: 0/0.31% 7/3.51% 8/96.18%
...
Which means that a frame_delay setting of 7 is very likely to work well.

Download:
Use PortAudio instead.

[Calamity]

Great job intealls! Thanks for this!

[intealls]

Great job intealls! Thanks for this!

Thanks Calamity! I've tried it on 4 computers as of now, and it seems to work pretty well. There is stuff that needs fixing, but it's definitely mature enough to warrant a pre-alpha release.

[timply]

I've installed asio4all and set it up exactly as you have it in the picture. Using the included mame build I'm not getting any sound at all. Is it possible asio4all is not compatible with all integrated sound cards? It's SoundMAX HD audio on an Asus Rampage II Gene motherboard.



Edit: Nevermind! Dumb me! I didn't create a new mame.ini with your version of the mame build. Its working now.

[intealls]

Edit: Nevermind! Dumb me! I didn't create a new mame.ini with your version of the mame build. Its working now.

Glad to hear it.

If you need any help, post here and I'll reply as soon as possible. What latency are you able to get? You should aim for something like 96-128.

Also, if you run with -v, you'll get an underrun/overrun counter at the bottom of the MAME log. The overruns/underruns should be hard to hear, but you can tweak a parameter for better results, I'd be glad to help out with this!

[timply]

I currently have it set to 96. I played a full game of NBA Maximum Hangtime (791 seconds) and didn't hear any unusual audio cues. My log says I had 46 overruns and 16 underruns. I'm not sure if that is good or bad.

[intealls]

I've currently have it set to 96. I played a full game of NBA Maximum Hangtime (791 seconds) and didn't hear any unusual audio cues. My log says I had 46 overruns and 16 underruns. I'm not sure if that is good or bad.

The implementation is currently very stringent with overruns and underruns. They shouldn't be too noticeable. The latency is excellent!

However, if the game is running at 100% or close to 100% all the time, I'd say that's too many. I'm gonna try this game when I get home, to see how it performs. What rig are you using btw?

If you start to notice crackling or similar, try opening up a command prompt and run batool with the parameters 0 90 4 1, and put the value you get (global rate, last one) in mame.ini, as the asio_cal_freq parameter. But, if you don't notice anything (I probably wouldn't, if I hadn't been intensely searching for audio crackles/pops the last month), you shouldn't bother.

Doing the batool measurement will most likely improve the over/underrun statistics a bit. If you really, really want to get the best possible results, do the optimization routine outlined in the original post.

Also, thank you for the feedback. It's pretty awesome that it's finally up and running on someone elses rig.

[timply]

My rig:
Core I7 960
8 megs of ram
win7 64
HD4350
Integrated SoundMAX HD audio

I played 18 holes of Golden Tee 2k twice. Once before running batool64 and once after.
before batool it was pretty bad, the sound effects were fine but the music played between rounds sounded garbled and after 870 seconds (99.96% speed) the over/under was pretty high at 1160/634.
after batool the sound was a lot better and after 997 seconds (99.95% speed) the over/under was 663/338.

I'm thinking I may need to raise my ASIO buffer size, would that be correct?

[intealls]

I played 18 holes of Golden Tee 2k twice. Once before running batool64 and once after.
before batool it was pretty bad, the sound effects were fine but the music played between rounds sounded garbled and after 870 seconds (99.96% speed) the over/under was pretty high at 1160/634.
after batool the sound was a lot better and after 997 seconds (99.95% speed) the over/under was 663/338.

I'm thinking I may need to raise my ASIO buffer size, would that be correct?

This is strange. Only games that have wildly varying game speeds should exhibit this many under/overruns, but GT2K on an i7 should really not be doing this. Does the rig have lots of stuff running in the background? Browsers, Hyperspin, etc?

The ASIO buffer size shouldn't have to be raised.

It will really help if you do a run with -asio_log, and attach the log here.

Edit:

I did a 2-hole run on my i5-2500k, with the following stats:

Code: [Select]

ASIO: Driver ASIO4ALL v2 initialized with latency 110,
      sample rate 48000.00, compensated sample rate 48001.000000,
      and an intermediate buffer size of 1536 samples
...
Average speed: 99.84% (268 seconds)
window_proc: WM_NCACTIVATE
blit_lock = TRUE
window_proc: WM_DESTROY
blit_lock = TRUE
ASIO: Average callback timeslice usage: 0.225060
ASIO: Overrun/underrun: 0/0


[cools]

The RAM looks a bit low to me.

[timply]

Nope, I don't have anything running in the background. I disabled most services when I installed the OS and I'm running mame from a command prompt.

I logged a couple of minutes of Golden Tee.

[intealls]

Nope, I don't have anything running in the background. I disabled most services when I installed the OS and I'm running mame from a command prompt.

I logged a couple of minutes of Golden Tee.

Thanks for this. Are you using frame_delay?

[timply]

Yeah. D3D with a frame delay of 7.

[intealls]

Yeah. D3D with a frame delay of 7.

Alright. Could you test running with ddraw, without frame_delay?

Edit:
Currently, there are issues with frame_delay, outlined in the other thread (http://forum.arcadecontrols.com/index.php/topic,141869), that greatly affect the implementation. I should add this to the top post.

[timply]

Using ddraw no over or under runs! 

[intealls]

Using ddraw no over or under runs! 

Nice

Thanks alot! If you continue to use this build, please post anything you encounter that seems wonky.

[timply]

Using ddraw no over or under runs! 

Nice

Thanks alot! If you continue to use this build, please post anything you encounter that seems wonky.

Will do!

[stellarola]

You bet your ass I will be trying this when I get home! 

Looking forward to these advancements!

[stellarola]

So I was finally able to test out the pre-alpha build. The results have been great! I'm running integrated audio atm (Realtek HD) and was able to successfully turn the buffer in ASIO4ALL down to 64 samples. 96 samples worked just fine as well.

Is there a benefit or loss to lowering the latency to 64 samples? Am I losing audio channels in games by doing this?

I always run GroovyMAME with ddraw and frame delay set to 1 as standard. This has proven to work fine for my setup to decrease input delay (always had input delays when set to 0). I haven't had any glitching from adjusting frame delay to 1 with this ASIO build...at least with my hardware.

Hardware:

Intel Pentium G258 3.2ghz (OC'd to 4.5ghz)
H97 motherboard
4GB DDR3
Radeon 4550 GPU
Realtek HD audio (integrated)
Windows 7 x64


There are some "glitches" if you want to call them that...

When you pause the game and return, the audio plays slightly out of sync for a second, then catches back up. Also, when I set my monitor preset from generic_15 to ms929 (my monitor) in mame.ini, i appear to be losing frames and the performance dips causes audio to become out of sync, even at 4.5ghz. That bug may just be related to groovymame and not this particular build. I'll need to further test to confirm this on other builds.

Anyway I can visually see/hear the difference in this build. I used Samurai Showdown II as a test, since I own the original hardware too. It seems practically spot on! The latency much more noticeable with dsound.

Thanks for adding this feature. I'm looking forward to more from both Calamity and intealls.

-stell

[stellarola]

On my Windows XP x64 box with x600 gpu I was not able to load the vmame64 executable. Error related to not being a valid Win32 program. Works fine in Windows 7 x64.

[intealls]

So I was finally able to test out the pre-alpha build. The results have been great! I'm running integrated audio atm (Realtek HD) and was able to successfully turn the buffer in ASIO4ALL down to 64 samples. 96 samples worked just fine as well.

Is there a benefit or loss to lowering the latency to 64 samples? Am I losing audio channels in games by doing this?

I always run GroovyMAME with ddraw and frame delay set to 1 as standard. This has proven to work fine for my setup to decrease input delay (always had input delays when set to 0). I haven't had any glitching from adjusting frame delay to 1 with this ASIO build...at least with my hardware.

Hardware:

Intel Pentium G258 3.2ghz (OC'd to 4.5ghz)
H97 motherboard
4GB DDR3
Radeon 4550 GPU
Realtek HD audio (integrated)
Windows 7 x64


There are some "glitches" if you want to call them that...

When you pause the game and return, the audio plays slightly out of sync for a second, then catches back up. Also, when I set my monitor preset from generic_15 to ms929 (my monitor), i appear to be losing frames and the performance dips causes audio to become out of sync, even at 4.5ghz. That bug may just be related to groovymame and not this particular build. I'll need to further test to confirm this on other builds.

Anyway I can visually see/hear the difference in this build. I used Samurai Showdown II as a test, since I own the original hardware too. It seems practically spot on! The latency much more noticeable with dsound.

Thanks for adding this feature. I'm looking forward to more from both Calamity and intealls.

-stell

Thanks alot for the feedback!

I haven't been able to test on Windows XP, since I only have W7 installations. Will check it out next week (we're in the middle of moving), and have a look at the other issues as well. I'll also try to release a ASIO-patched version of the official 0.155 build sometime during next week as well.

[Calamity]

I still haven't tested this myself and I'm eager to do it. The implementation of the last patch (0.015d) took me so long that I didn't have time for anything else.

[stellarola]

Would love to try with new switches. Also adjusting latency in mame.ini (changing from 2.0 to 1.0 results in loss of audio).

[adder]

I always run GroovyMAME with ddraw and frame delay set to 1 as standard. This has proven to work fine for my setup to decrease input delay (always had input delays when set to 0)

i think that if you are using directdraw, there is no reason to/gain in using frame_delay set to 1

When you pause the game and return, the audio plays slightly out of sync for a second, then catches back up.

something to try is, in your pc BIOS, do you have a feature called 'speedstep/speedstepping' (or E.I.S.T) enabled? if so, disable it.

a little extra thing, many of us set in mame.ini:  sleep to 0     (Calamity, could sleep 0 become default in groovymame sometime, or is it undetermined if it is 'safe'/wiser/better than sleep 1)

[stellarola]

I always run GroovyMAME with ddraw and frame delay set to 1 as standard. This has proven to work fine for my setup to decrease input delay (always had input delays when set to 0)

i think that if you are using directdraw, there is no reason to/gain in using frame_delay set to 1

When you pause the game and return, the audio plays slightly out of sync for a second, then catches back up.

something to try is, in your pc BIOS, do you have a feature called 'speedstep/speedstepping' (or E.I.S.T) enabled? if so, disable it.

a little extra thing, many of us set in mame.ini:  sleep to 0     (Calamity, could sleep 0 become default in groovymame sometime, or is it undetermined if it is 'safe'/wiser/better than sleep 1)

Does frame_delay setting not interact with ddraw in any way? Possibly just a placebo effect then. I swear my input is increased when set to '1'. Especially in "Shinobi". The ninja star just seems to react to my input quicker...I'm not sure.

As far as speedstep goes I've already taken that. It doesn't appear to be speedstep that is causing the audio to play out of sync. This issue does not occur using directsound.

[Calamity]

Of course -frame_delay works with ddraw, even setting it to "1", it's only that using a value of "1" for all games reveals a missunderstanding of how this option works. As it's been explained, one should try to use the highest value that's stable for a certain game in a particular system, instead of the lowest common denominator.

That said, you shouldn't use -frame_delay combined with inteall's ASIO implementation. This is because -frame_delay turns the speed percentage unreliable, and this value is used by the ASIO implementation. This is explained in inteall's original thread.

[stellarola]

Of course -frame_delay works with ddraw, even setting it to "1", it's only that using a value of "1" for all games reveals a missunderstanding of how this option works. As it's been explained, one should try to use the highest value that's stable for a certain game in a particular system, instead of the lowest common denominator.

That said, you shouldn't use -frame_delay combined with inteall's ASIO implementation. This is because -frame_delay turns the speed percentage unreliable, and this value is used by the ASIO implementation. This is explained in inteall's original thread.

I guess I can't have my cake and eat it too in that case. It's either lower latency audio or lower latency control input? I'm not hearing any issues with the audio doing it this way (so far that i notice).

[intealls]

Of course -frame_delay works with ddraw, even setting it to "1", it's only that using a value of "1" for all games reveals a missunderstanding of how this option works. As it's been explained, one should try to use the highest value that's stable for a certain game in a particular system, instead of the lowest common denominator.

That said, you shouldn't use -frame_delay combined with inteall's ASIO implementation. This is because -frame_delay turns the speed percentage unreliable, and this value is used by the ASIO implementation. This is explained in inteall's original thread.

I guess I can't have my cake and eat it too in that case. It's either lower latency audio or lower latency control input? I'm not hearing any issues with the audio doing it this way (so far that i notice).

Hmm, with frame_delay 1 and ddraw I seem to be getting fairly good results. In samsho4, no over/underruns. Also, running shinobi with -frame_delay 1 + ddraw seems to work just as well. I need to do more testing with frame_delay and ddraw (at first glance it seems to behave differently compared to d3d?). When using a large value however (7 + ddraw), things start to behave weirdly. But (I think) a setting of 1 should probably be ok.

Thanks for notifying me of the pause problem, it's been put onto the todo list.

Before testing more, please do a preliminary calibration using batool64. Open a command prompt and run "batool64 0 90 4 1". Configure ASIO4ALL the same way you have configured MAME using the tray icon. Press CTRL-C and rerun the command. When finished, put the last value (global rate) as the asio_cal_freq parameter in mame.ini (or as a command line switch). Try the same games you're having problems with, and see if they behave better.

I tried the ms929 preset, but it seems to work fairly well here. Please try doing the calibration, and try the following switches (don't mind the large audio_latency value, it does not increase the latency the same way as the dsound implementation)

Code: [Select]

-audio_latency 5 -nosleep -priority 1 -asio_cal_freq [value from batool]

Also, lowering the latency to 64 samples isn't recommended. 96 or upwards should probably be used, this is due to the tick frequency of Windows, which is 1000 Hz. A setting of 96 tells the ASIO subsystem to fetch new data 500 times/sec, instead of 750 times/sec, which will probably help avoid unforeseen problems.

[Calamity]

Hmm, with frame_delay 1 and ddraw I seem to be getting fairly good results.

Good news then! So my information was outdated

It will be interesting to try this with the new 0.015d patch that I believe should provide a more stable speed percentage when using frame_delay.

[intealls]

Hmm, with frame_delay 1 and ddraw I seem to be getting fairly good results.

Good news then! So my information was outdated

It will be interesting to try this with the new 0.015d patch that I believe should provide a more stable speed percentage when using frame_delay.

Awesome news!

Can't wait to try it out.

The coming days I'll experiment more with frame_delay + ddraw, after looking at the XP problem, to see more about how it behaves compared to d3d. So far, I haven't seen any 'speed spikes' (as mentioned in the other thread) using frame_delay 1 and ddraw, which is excellent!

[stellarola]

Hmm, with frame_delay 1 and ddraw I seem to be getting fairly good results.

Good news then! So my information was outdated

It will be interesting to try this with the new 0.015d patch that I believe should provide a more stable speed percentage when using frame_delay.

Awesome news!

Can't wait to try it out.

The coming days I'll experiment more with frame_delay + ddraw, after looking at the XP problem, to see more about how it behaves compared to d3d. So far, I haven't seen any 'speed spikes' (as mentioned in the other thread) using frame_delay 1 and ddraw, which is excellent!

I'm sure I'm missing something. Was there a particular reason behind building GM with ASIO using version 0.155 instead of the latest 0.156 with new switchres?

Great work intealls and calamity. I'll be around to test, capture video etc. if needed.

Check out this little video I did using GroovyMAME and real Neo Geo MVS hardware:

[Calamity]

I'm sure I'm missing something. Was there a particular reason behind building GM with ASIO using version 0.155 instead of the latest 0.156 with new switchres?

When intealls compiled his build MAME 0.156 wasn't around yet, that's all.

Thanks for the video! It's super cool to be able to see that side by side! (I guess it was hard to synchronize both!)

[stellarola]

I'm sure I'm missing something. Was there a particular reason behind building GM with ASIO using version 0.155 instead of the latest 0.156 with new switchres?

When intealls compiled his build MAME 0.156 wasn't around yet, that's all.

Thanks for the video! It's super cool to be able to see that side by side! (I guess it was hard to synchronize both!)

Haha, it was a bit hard to sync them up. I entered service mode on both and tried to exit at the same time. Pretty damn impressive! I was reading on Haze's blog about how MAME finally added correct colors back in May. I can say thats a true statement.

Article here: http://mamedev.emulab.it/haze/2014/05/23/3487/

[Calamity]

I'd say MAME devs will be proud of watching that video... although they won't admit it publically 

[intealls]

I'm sure I'm missing something. Was there a particular reason behind building GM with ASIO using version 0.155 instead of the latest 0.156 with new switchres?

When intealls compiled his build MAME 0.156 wasn't around yet, that's all.

Thanks for pointing this out. Hadn't noticed that 0.156 had been released. In between work and moving/painting/cleaning there unfortunately isn't a whole lot of time left for GM hacking. However the non-work related part is done so now I'll have more time on my hands. I'm already baking a new 0.156 executable.

stellarola, what type of CPU are you using on the XP box? I think the binary launch problem might be related to a flag I use when building.

[stellarola]

I'm sure I'm missing something. Was there a particular reason behind building GM with ASIO using version 0.155 instead of the latest 0.156 with new switchres?

When intealls compiled his build MAME 0.156 wasn't around yet, that's all.

Thanks for pointing this out. Hadn't noticed that 0.156 had been released. In between work and moving/painting/cleaning there unfortunately isn't a whole lot of time left for GM hacking. However the non-work related part is done so now I'll have more time on my hands. I'm already baking a new 0.156 executable.

stellarola, what type of CPU are you using on the XP box? I think the binary launch problem might be related to a flag I use when building.

Intel Core 2 Duo E8400. Also to note, I'm running a build of XP called 'Tiny XP'. The OS may be missing some important files for this build possibly?

The regular GroovyMAME executable launches without a problem.

[intealls]

I'm sure I'm missing something. Was there a particular reason behind building GM with ASIO using version 0.155 instead of the latest 0.156 with new switchres?

When intealls compiled his build MAME 0.156 wasn't around yet, that's all.

Thanks for pointing this out. Hadn't noticed that 0.156 had been released. In between work and moving/painting/cleaning there unfortunately isn't a whole lot of time left for GM hacking. However the non-work related part is done so now I'll have more time on my hands. I'm already baking a new 0.156 executable.

stellarola, what type of CPU are you using on the XP box? I think the binary launch problem might be related to a flag I use when building.

Intel Core 2 Duo E8400. Also to note, I'm running a build of XP called 'Tiny XP'. The OS may be missing some important files for this build possibly?

The regular GroovyMAME executable launches without a problem.

Okay, thanks, it's probably not the flag then. I'm using the latest MSVC compiler to build (seems to produce slightly faster builds, and BASSASIO seems to have problems with 64-bit MinGW), which seem to require some extra fiddling for the binaries to work with XP. I'll have to fix up a machine with XP64 to do some tests, hopefully I'll have it all sorted before next week.

Also, here's 0.156 + ASIO! http://www.mediafire.com/download/wctpxe2e1egw657/gm156-asio-pre0-64.zip

[stellarola]

I'm sure I'm missing something. Was there a particular reason behind building GM with ASIO using version 0.155 instead of the latest 0.156 with new switchres?

When intealls compiled his build MAME 0.156 wasn't around yet, that's all.

Thanks for pointing this out. Hadn't noticed that 0.156 had been released. In between work and moving/painting/cleaning there unfortunately isn't a whole lot of time left for GM hacking. However the non-work related part is done so now I'll have more time on my hands. I'm already baking a new 0.156 executable.

stellarola, what type of CPU are you using on the XP box? I think the binary launch problem might be related to a flag I use when building.

Intel Core 2 Duo E8400. Also to note, I'm running a build of XP called 'Tiny XP'. The OS may be missing some important files for this build possibly?

The regular GroovyMAME executable launches without a problem.

Okay, thanks, it's probably not the flag then. I'm using the latest MSVC compiler to build (seems to produce slightly faster builds, and BASSASIO seems to have problems with 64-bit MinGW), which seem to require some extra fiddling for the binaries to work with XP. I'll have to fix up a machine with XP64 to do some tests, hopefully I'll have it all sorted before next week.

Also, here's 0.156 + ASIO! http://www.mediafire.com/download/wctpxe2e1egw657/gm156-asio-pre0-64.zip

I just did a quick test using same settings as 155 and I'm actually experiencing issues with audio cutting in and out. I don't appear to be losing frames though. Experienced this in multiple games. I'll run that tool tomorrow and send you feedback.

Thanks for compiling

-stell

[stellarola]

I just did this one for fun. It's the original pre-alpha build (gm 155).

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

[Paradroid]

I just did this one for fun.

Awesome video! Thanks for taking the time.