The NEW Build Your Own Arcade Controls
Software Support => GroovyMAME => Topic started by: intealls on November 01, 2014, 09:14:31 pm
-
Notice: This is deprecated. Use the native PortAudio feature instead.
This alternative GM build uses BASSASIO (www.un4seen.com (http://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 (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/ (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 (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:
multithreading 1
Required settings for 60hz LCD:
monitor lcd
refresh_dont_care 1
multithreading 1
Required settings for 120hz LCD:
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 (http://forum.arcadecontrols.com/index.php/topic,142143.msg1517321.html#msg1517321) 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:
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.
-
Great job intealls! Thanks for this!
-
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. :)
-
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.
-
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!
-
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.
-
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. :)
-
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?
-
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:
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
-
The RAM looks a bit low to me.
-
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.
-
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?
-
Yeah. D3D with a frame delay of 7.
-
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 (http://forum.arcadecontrols.com/index.php/topic,141869)), that greatly affect the implementation. I should add this to the top post.
-
Using ddraw no over or under runs! :applaud:
-
Using ddraw no over or under runs! :applaud:
Nice :)
Thanks alot! If you continue to use this build, please post anything you encounter that seems wonky.
-
Using ddraw no over or under runs! :applaud:
Nice :)
Thanks alot! If you continue to use this build, please post anything you encounter that seems wonky.
Will do!
-
You bet your ass I will be trying this when I get home! :afro:
Looking forward to these advancements!
-
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
-
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.
-
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.
-
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.
-
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).
-
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)
-
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.
-
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.
-
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).
-
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)
-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. :)
-
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.
-
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!
-
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:
http://youtu.be/sZfTZ6iFiJs (http://youtu.be/sZfTZ6iFiJs)
-
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!)
-
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/ (http://mamedev.emulab.it/haze/2014/05/23/3487/)
-
I'd say MAME devs will be proud of watching that video... although they won't admit it publically ;)
-
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.
-
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.
-
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 (http://www.mediafire.com/download/wctpxe2e1egw657/gm156-asio-pre0-64.zip)
-
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 (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
-
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.
http://youtu.be/IM-dRD1Aob4 (http://youtu.be/IM-dRD1Aob4)
-
I just did this one for fun.
Awesome video! Thanks for taking the time. :)
-
I just did this one for fun. It's the original pre-alpha build (gm 155).
Thought you guys would get a kick out of it. The audio is playing out of both cabinets. Stereo on GroovyMAME, Mono on the MVS hardware.
GroovyMAME is on the right, btw.
http://youtu.be/IM-dRD1Aob4 (http://youtu.be/IM-dRD1Aob4)
Awesome! :)
Thanks for this!
-
It will be interesting to try this with the new 0.015d patch that I believe should provide a more stable speed percentage when using frame_delay.
SwitchRes 0.015d seems to have done away with the neodrift speed oscillations (and probably many other games too) mentioned in http://forum.arcadecontrols.com/index.php?topic=141869.0, (http://forum.arcadecontrols.com/index.php?topic=141869.0,) which is great!
After doing lots (and lots) of testing, I think I can conclude that frame_delay seems to affect different computers/installations differently, at least in regards to audio sample generation. This also appears dependent on what game is run, and if d3d/ddraw is used.
I've done tests on two computers. One i3 3.4GHz with a Z97 chipset, and a Core 2 Duo 2.95GHz with a 945PL chipset. Both are running Windows 7, with the latest CRT emudriver and GM156/SwitchRes 0.015d.
The 'speed spikes' mentioned in http://forum.arcadecontrols.com/index.php?topic=141869.0 (http://forum.arcadecontrols.com/index.php?topic=141869.0) still appear on the i3 when using d3d, however, when using ddraw, they don't. So pbobble (-bench 30 = 1835%) with frame_delay 8 and ddraw work perfectly on this rig. However, with the same settings (fd8 and ddraw), msword (-bench 30 = 2564%) does not. Even though no speed spikes appear with ddraw, sample generation seem to be intermittently delayed (see attached image), which will lead to underruns, if aiming for the best possible latency.
No speed spikes appear on the Core 2, with neither d3d nor ddraw, but the intermittent sample generation delay problem seems to appear here also.
What to make of this? At this point, I don't really know. Some games work great with frame_delay, and some, which probably should, don't. Switching between D3D/DDraw seems to affect the sample generation process in some way. Also, increasing -asio_holdoff to 1536 will help mitigate buffer over-/underruns, but will add 16 ms of latency.
In conclusion, if anyone's interested in testing frame_delay in combination with ASIO, and you're getting too many over-/underruns, try switching between ddraw and d3d, since it seems to have an effect. Also try setting -asio_holdoff 1536. And, just like Calamity says, frame_delay should be used as a per-game setting. If tweaking for a particular game, I'm sure good results can be achieved, at the probable cost of higher latency.
Unrelated to frame_delay, after doing more tests on XP, the conclusion is that ASIO4ALL does not work nearly as good as on 7, so you really need a proper ASIO-capable card (such as an old SB with the kX driver) for stuff to work. Using the i3, the Z97 chipset does not support XP, and on this setup I couldn't get kX to work satisfactorily (also, the 64-bit GM+ASIO executable didn't even launch, and spat out an illegal instruction exception in powf). On the Core 2, kX worked just fine with a 128 sample ASIO buffer. So mileage with XP will undoubtedly vary.
Edit: I've just noticed more stuff which seems somewhat weird, I'm gonna have to do some tests and report later on.
-
What about ASIO for normal computer setups with normal computer monitors?
Are you planning to do a standalone diff for baseline MAME?
-
What about ASIO for normal computer setups with normal computer monitors?
Are you planning to do a standalone diff for baseline MAME?
Not right now. There's still lots of stuff that needs fixing, and even more stuff that needs figuring out. But in time I could make a separate patch for mainline.
In the meantime, GM can be configured to work just fine with a normal monitor.
-
Intealls, thank you for your work on this. It has given me yet another thing to obsess over. I'm coming here from the Raw Input vs Direct Input Lag thread (http://forum.arcadecontrols.com/index.php/topic,145174.msg1512137.html#msg1512137) because of a finding there that involves your ASIO patch.
Luckily, with a default mame.ini generated from the .156 build you've posted here, there is no additional lag compared to vanilla GroovyMAME. Input is reflected on the 1st or 2nd frame following input with frame_delay 9 set. However, with the ASIO4ALL solution, I had to set my asio_holdoff value to 1152 to avoid obviously audible overrun/underrun issues. This results in increasing lag so that input is often reflected on the 3rd frame after it is received. I don't really understand how asio_holdoff works. You mentioned that increasing it can increase latency, but I assumed you meant audio only. It appears to affect input latency as well. Perhaps you were already aware.
So, now I'm trying to come up with a lower latency solution so I can use your patch without incurring additional lag, little as it is. Like I said, I'm obsessed now. It looks like getting a new cheap motherboard without any PCI slots was a mistake, because I can't use my old Creative cards with the kX driver without one. I have a USB Behringer UCA202 that has a native ASIO driver that I am able to play through with programs like Foobar2000, but I haven't figured out how to get it working with your patch yet. Batool recognizes it after I registered its asio DLL in Windows, but it doesn't seem to like the syntax I am using for testing. I'll play with it some more and post some results later, but I think I'll end up trying to find a PCI express card that will work with it instead. Is anyone aware of any?
*Edit - Additional testing showed that there is currently no good evidence that ASIO settings impact input lag. It shouldn't cause any issues in this area.
-
I found a Realtek native ASIO driver. It plays audio through foobar2000's ASIO component successfully on my ALC888. Perhaps others will find it useful. I assume these might provide better latency than ASIO4ALL, but really have no idea. Installation Instructions are included.
Realtek_ASIO_driver_v1.0.0.1.zip (https://mega.co.nz/#!TU0lWDwI!54li7Lc45BONRVksIrpbiJ6lzDB5s1TlP1pEqmF3Xxg)
However, I can't get BATool64.exe or GroovyMAME to recognize this driver either. the -asio_log option produces no log in this scenario. All I get from the -V output is "ASIO: Unable to initialize device 0"
*Edit - Nevermind. The included driver appears to be 32-bit only.
-
I had to set my asio_holdoff value to 1152 to avoid obviously audible overrun/underrun issues. This results in increasing lag so that input is often reflected on the 3rd frame after it is received. I don't really understand how asio_holdoff works. You mentioned that increasing it can increase latency, but I assumed you meant audio only. It appears to affect input latency as well. Perhaps you were already aware.
Strange, how are you measuring the latency? The only modification I can think could possibly affect the input latency is that the audio is updated at a higher frequency than with vanilla GM.
asio_holdoff simply waits until there are N samples in the buffer before starting playback. Setting it to 1152 waits until there are 24 milliseconds worth of audio ready to be played before beginning playback. This will help when the audio updates come from GM somewhat irregularly, which seems to be the case when using a high frame_delay value with a demanding game.
-
Thanks for the reply! So when you say that "it" waits 24 milliseconds for enough audio to be ready, what do you mean, exactly? Should the sound only be 24 ms slower, or the emulation entirely? 24 ms is roughly the amount of input lag that was added when I used increased audio_latency and asio_holdoff values with ASIO4ALL, so I'm suspicious.
The tests were performed as shown in the Raw Input vs Direct Input (http://forum.arcadecontrols.com/index.php/topic,145174.msg1511736.html#msg1511736) thread. An LED is wired to a button and then a CRT screen is recorded with a high-speed camera to observe the delay from when a button is pressed until the result shows on-screen.
You can see that the first results I posted in that thread are about 1 frame laggier than the subsequent results. This was with DirectDraw and Frame_Delay 0. I compared the mame.ini file to a fresh one and the only differences were video ddraw, asio_holdoff, and audio_latency. ddraw vs d3d with identical frame_delay values had basically identical input latencies in my testing, so that led me to test the Asio settings, which I was able to confirm caused additional lag.
However, I've done so many tests that my memory is becoming foggy, and I wonder if I made a mistake somewhere with conflicting INI settings regarding frame_delay. I didn't save or post my subsequent tests, which was a mistake. I'll run more tests and share my logs and configurations so you don't just have to take my word for it.
Otherwise, since the last time, I've tested my older Core2Duo system with both a first-gen Audigy with the Kx driver and an Asus Xonar DG with Uni drivers. The lowest ASIO latencies available with each work well in most cases with audio_latency 2.0 and asio_holdoff 832. The Xonar is kind of weird, because only the lowest setting of 1ms works without audio drops, which your logs report as a latency of 96. Higher latencies all seem to cause issues.
I picked up a PCIe Xonar DGX for my newer system yesterday and it works okay. I haven't gotten to test much, but I get better results with d3d and frame_delay than DirectDraw now. Neo Geo games with Frame Delay 8 are completely solid, as are CPS 1 and 2 games at frame_delay 9, but Street Fighter 3 3rd Strike at Frame_delay 8 is erratic despite bench speeds around 1500%, unfortunately. It runs great without frame_delay enabled. I need to do some more testing and see if I'm okay with leaving it off for this game and using Direct Draw. The reduced lag of Direct Draw vs d3d alone is probably fine, but I've just become obsessed with having the lowest possible latencies for input and sound.
By the way, what ASIO settings would be equivalent to Direct Sound with Audio_Latency 1.0?
-
Thanks for the thorough reply!
So when you say that "it" waits 24 milliseconds for enough audio to be ready, what do you mean, exactly? Should the sound only be 24 ms slower, or the emulation entirely?
Only the audio should be affected.
However, I've done so many tests that my memory is becoming foggy, and I wonder if I made a mistake somewhere with conflicting INI settings regarding frame_delay. I didn't save or post my subsequent tests, which was a mistake. I'll run more tests and share my logs and configurations so you don't just have to take my word for it.
Thanks, I certainly know the feeling. :)
Otherwise, since the last time, I've tested my older Core2Duo system with both a first-gen Audigy with the Kx driver and an Asus Xonar DG with Uni drivers. The lowest ASIO latencies available with each work well in most cases with audio_latency 2.0 and asio_holdoff 832. The Xonar is kind of weird, because only the lowest setting of 1ms works without audio drops, which your logs report as a latency of 96. Higher latencies all seem to cause issues.
I picked up a PCIe Xonar DGX for my newer system yesterday and it works okay. I haven't gotten to test much, but I get better results with d3d and frame_delay than DirectDraw now. Neo Geo games with Frame Delay 8 are completely solid, as are CPS 1 and 2 games at frame_delay 9, but Street Fighter 3 3rd Strike at Frame_delay 8 is erratic despite bench speeds around 1500%, unfortunately. It runs great without frame_delay enabled. I need to do some more testing and see if I'm okay with leaving it off for this game and using Direct Draw. The reduced lag of Direct Draw vs d3d alone is probably fine, but I've just become obsessed with having the lowest possible latencies for input and sound.
By the way, what ASIO settings would be equivalent to Direct Sound with Audio_Latency 1.0?
I don't remember if the audio_latency parameter affects the ASIO implementation with the build posted here. I could patch up the latest GM and refresh my memory a bit, I'll probably have it done sometime this weekend. But -audio_latency 1.0 with dsound seems to add about 75 milliseconds compared to ASIO, which would correspond to an -asio_holdoff setting of about 3600.
-
3600, eh? That's good to know. Thanks!
I have good news! It looks like I was wrong. Using Audio_latency 5.0 and asio_holdoff 1152 does not appear to introduce input lag. I can only reproduce results that consistently show input on the 3rd gameplay frame with frame_delay 0, so I assume when I was testing before, I still had frame_delay set at 0 through INI confusion. All of my asio results with frame_delay 9 and d3d were in the 1-2 frame range.
Videos Zip (https://mega.co.nz/#!mFckATwb!C0yiggygRo9S91sRU3L2j9C1sVmg5yinRff2XdnQIdE)
Logs and INIs zip (https://mega.co.nz/#!rVE0hDoQ!hmMYUFsG0aCyzMcdXVGgDg2YsNan21LD9l9yb9Refhw)
Speadsheet with frame counts (https://docs.google.com/spreadsheets/d/1dHtVoEpU4K-x_Ohi3aeYbk5dIv_RPW05iUK108R0s7Y/edit?usp=sharing) (240FPS. Divide by 4 and discard decimal for the gameplay frame input was shown on)
*Edit - Removed some speculation.
-
. I could patch up the latest GM and refresh my memory a bit, I'll probably have it done sometime this weekend.
I forgot to mention that I would greatly appreciate this. I haven't investigated how to do it myself yet. Now that MAME and MESS are merged as of .162, would this mean that the ASIO functionality would work with MESS drivers as well?
-
. I could patch up the latest GM and refresh my memory a bit, I'll probably have it done sometime this weekend.
I forgot to mention that I would greatly appreciate this. I haven't investigated how to do it myself yet. Now that MAME and MESS are merged as of .162, would this mean that the ASIO functionality would work with MESS drivers as well?
Thanks alot for your tests. Great to know that the ASIO stuff does not seem to affect the input latency.
Building with ASIO is a pain right now, since MAME just recently updated its build system, and GMASIO (64-bit) needs to be built using Visual Studio. I also had to employ a couple of truly terrible hacks to the sound structures, since there were changes there a couple of versions back.
Nonetheless, here's 0.162 :) It includes both MAME and MESS.
http://www.mediafire.com/download/n2jyl6f773p530h/gmame162-asio.zip (http://www.mediafire.com/download/n2jyl6f773p530h/gmame162-asio.zip)
EDIT: Also, -audio_latency 5.0 is no longer needed. The only parameter that affects the latency is -asio_holdoff (and of couse the latency of the ASIO driver).
-
Awesome, thank you! SNES and Genesis are the only MESS drivers I've tried so far, but they're working great! Also, with .156 and The Xonar DGX, I was getting crashes with CPS1 and CPS2 games at Frame_delay 9 with d3d (My machine can't handle frame_delay 9 with these drivers with ddraw, it seems). These crashes are gone now! I had an easy way to reproduce them before, but can't cause a crash regardless now. I don't even get any overruns or underruns with default asio_holdoff 832 in these drivers anymore. I'll have to play with it a lot more, but initially this seems really great. Thanks again!
-
Awesome, thank you! SNES and Genesis are the only MESS drivers I've tried so far, but they're working great! Also, with .156 and The Xonar DGX, I was getting crashes with CPS1 and CPS2 games at Frame_delay 9 with d3d (My machine can't handle frame_delay 9 with these drivers with ddraw, it seems). These crashes are gone now! I had an easy way to reproduce them before, but can't cause a crash regardless now. I don't even get any overruns or underruns with default asio_holdoff 832 in these drivers anymore. I'll have to play with it a lot more, but initially this seems really great. Thanks again!
No problem :)
Again, thanks a lot for the tests. Also, did you have to use batool to get a good calibration with the Xonar DGX? Thinking of picking one up.
-
You're welcome! Yes, I ran a long calibration. With HPET off in BIOS and bcdedit /set useplatformclock true, I get 48002.356. The Xonar DG on my older Core2Duo machine got a similar setting. I assume the DGX is the same card, just with a PCI express interface. The variations are worse than my Realtek onboard sound, but within 1hz. I'll run another calibration and share the log. It probably doesn't work as well your audigy/kx driver solution, but the low dpc latency option in the UNi Xonar drivers seems pretty good. Here are a few examples of games and settings I'm using to get to the point where I can't hear any problems, and few or no overruns/underruns show in logs. This is on a Haswell Pentium G3258 at 4.6Ghz
Neo Geo - asio holdoff 832, frame_delay 8, ddraw
CPS1 and 2 - asio holdoff 832, frame_delay 9, d3d (ddraw performs badly at FD9 on my machine, but d3d is great and stable with .162 in these drivers)
CPS3 - asio holdoff 1536, frame_delay 8, ddraw
Cave - asio holdoff 1536, frame_delay 9, ddraw
-
Here is the log (https://mega.co.nz/#!mNUBibJA!qmEzk77sxEK0Hm0882YmaLt4CFAqSvlCQ9knSYbuamo) of my overnight calibration of the Xonar DGX. The variation is less than I originally stated.
-
Here is the log (https://mega.co.nz/#!mNUBibJA!qmEzk77sxEK0Hm0882YmaLt4CFAqSvlCQ9knSYbuamo) of my overnight calibration of the Xonar DGX. The variation is less than I originally stated.
Now that's a proper calibration. :) I'm gonna order one to try out, since they're decently priced.
Neo Geo - asio holdoff 832, frame_delay 8, ddraw
CPS1 and 2 - asio holdoff 832, frame_delay 9, d3d (ddraw performs badly at FD9 on my machine, but d3d is great and stable with .162 in these drivers)
CPS3 - asio holdoff 1536, frame_delay 8, ddraw
Cave - asio holdoff 1536, frame_delay 9, ddraw
I'm gonna try these settings on my i3 3.4 GHz, to see if the same performance can be achieved on a completely different rig, with ASIO4ALL/kX (and soon DGX). Hopefully, I'll see similar results. If the same results can be shown consistently across multiple rigs/drivers, a 'known working settings' table could be put together.
Thanks again and please continue to post your findings, it's greatly appreciated! :)
-
Good luck! A known working settings table sounds like a good idea.
I've been doing some more testing with this new MAME version to make sure no input lag snuck into my favorite games. I have found one scenario where it has, but maybe it was there before. I get basically no over or underruns with direct draw and Neo Geo games, so I've been trying it with everything. However, with Street Fighter 3 Third Strike at frame_delay 8 and asio_holdoff 1536, it appears that it suffers from around 1 extra frame of lag compared to Direct3D. Perhaps this is actually what I ran into with some of my other testing, rather than accidentally having frame_delay set at 0. Here are the videos. Rather than include logs, I recorded myself opening the CPS3.INI file to show that the video setting changed from d3d to ddraw. This was the only change between tests. I counted the first 20 samples of each video and include some statistics below.
sfiii3u D3D (https://mega.co.nz/#!LctXyZxJ!hmX_lJUkMtllEPhJIwZU4MtYI_1lRPgKLU15ljW0BC8)
Next Frame Responses - 8/20
3rd Frame Responses - 0/20
sfiii3u DDRAW (https://mega.co.nz/#!WB9yUI6I!GKH-tEI1vW1VBaqAK-gsjKX9W2zOore0KIiTMDHqCs4[/url)
Next Frame Responses - 1/20
3rd Frame Responses - 2/20
I've recorded several sfiii3u tests and have gotten similar results each time. I've never seen a 3rd frame result with d3d at frame_delay 8 in this game. I ran the same test with Neo Geo (garouh) at Frame_Delay 8 and asio_holdoff 832. In that test, I didn't see any significant input delay difference between d3d and ddraw. I can't get next-frame input response with Neo Geo no matter what I do, and the spread of 2nd and 3rd frame responses appeared equal. Audio stability is basically perfect with ddraw here, so I'm happy to keep using it.
Even though Calamity has said that ddraw keeps the CPU busy longer than d3d, I'm not sure what the difference would be in the sfiii3u case. -bench 300 showed 1640% with d3d and 1633% with ddraw, which are both significantly better than my Neo Geo performance, so I don't know. Anyway, I'll be trying to use d3d whenever I use frame_delay, unless ASIO performance with ddraw is significantly superior and I can confirm no increased input delays.
-
I've been doing some more testing with this new MAME version to make sure no input lag snuck into my favorite games. I have found one scenario where it has, but maybe it was there before. I get basically no over or underruns with direct draw and Neo Geo games, so I've been trying it with everything. However, with Street Fighter 3 Third Strike at frame_delay 8 and asio_holdoff 1536, it appears that it suffers from around 1 extra frame of lag compared to Direct3D. Perhaps this is actually what I ran into with some of my other testing, rather than accidentally having frame_delay set at 0. Here are the videos. Rather than include logs, I recorded myself opening the CPS3.INI file to show that the video setting changed from d3d to ddraw. This was the only change between tests. I counted the first 20 samples of each video and include some statistics below.
sfiii3u D3D (https://mega.co.nz/#!LctXyZxJ!hmX_lJUkMtllEPhJIwZU4MtYI_1lRPgKLU15ljW0BC8)
Next Frame Responses - 8/20
3rd Frame Responses - 0/20
sfiii3u DDRAW (https://mega.co.nz/#!WB9yUI6I!GKH-tEI1vW1VBaqAK-gsjKX9W2zOore0KIiTMDHqCs4[/url)
Next Frame Responses - 1/20
3rd Frame Responses - 2/20
I've recorded several sfiii3u tests and have gotten similar results each time. I've never seen a 3rd frame result with d3d at frame_delay 8 in this game. I ran the same test with Neo Geo (garouh) at Frame_Delay 8 and asio_holdoff 832. In that test, I didn't see any significant input delay difference between d3d and ddraw. I can't get next-frame input response with Neo Geo no matter what I do, and the spread of 2nd and 3rd frame responses appeared equal. Audio stability is basically perfect with ddraw here, so I'm happy to keep using it.
Ok, have you done these tests against vanilla GM? If vanilla GM and GMASIO do not behave the same, I've got homework to do. :)
EDIT: A while back, I put together a script to help me test various ASIO-related settings, if you're only testing for over/underruns, you might find them useful (rename to .bat).
-
I just tested vanilla GroovyMAME .162 and the results were the same. I also tested sf2 at frame_delay 9, which I can run at a much higher percentage than sfiii3u, and it also had the same results. Out of the first 20 frame counts, all showed response on the 2nd gameplay frame except one, which showed on the 3rd. GM 1.56 with the ASIO patch also behaves the same. I don't think it matters, but all my testing has been with RawInput.
At the moment, I don't know of any evidence that shows Direct Draw allowing for next-frame response times in GM with frame_delay 9. At least, I can't produce any on this Windows 7 machine. Of course, it produces much less lag than d3d when frame_delay is not used, so I leave it as my default in mame.ini for when I have not configured a game-specific ini. My tests show d3d responds on the 5th or 6th frame in this case, vs direct draw's 2nd or 3rd. Later when I have a chance to upload the videos, I'll make a post in the input lag thread.
Thanks for the batch files! I'll try them out.
-
I just tested vanilla GroovyMAME .162 and the results were the same. I also tested sf2 at frame_delay 9, which I can run at a much higher percentage than sfiii3u, and it also had the same results. Out of the first 20 frame counts, all showed response on the 2nd gameplay frame except one, which showed on the 3rd. GM 1.56 with the ASIO patch also behaves the same. I don't think it matters, but all my testing has been with RawInput.
At the moment, I don't know of any evidence that shows Direct Draw allowing for next-frame response times in GM with frame_delay 9. At least, I can't produce any on this Windows 7 machine. Of course, it produces much less lag than d3d when frame_delay is not used, so I leave it as my default in mame.ini for when I have not configured a game-specific ini. My tests show d3d responds on the 5th or 6th frame in this case, vs direct draw's 2nd or 3rd. Later when I have a chance to upload the videos, I'll make a post in the input lag thread.
Thanks for the batch files! I'll try them out.
Ok, thanks. I'm gonna thoroughly try the settings you posted later today, I've done some preliminary tests and so far I see a strong correlation with the results you see.
It's actually quite awesome to be able to play deathsml with fd 9 :)
Once again, thanks for your tests, I've been scratching my head over the ddraw/d3d differences ever since I started developing this patch, so it's great that more light is being shed on the matter.
-
It's actually quite awesome to be able to play deathsml with fd 9 :)
You've confirmed this?! I think I can only run at FD5 or so on my 4.6ghz 2 core Haswell g3258 with -mt. If you're referring to when I said I could run "cave" games at fd 9, I meant the "cave" driver used for their 90s games like Donpachi. I can't run any cv1k games at speeds necessary for fd9, though I was only going by speed and I don't think I've bothered trying it out.
-
It's actually quite awesome to be able to play deathsml with fd 9 :)
You've confirmed this?! I think I can only run at FD5 or so on my 4.6ghz 2 core Haswell g3258 with -mt. If you're referring to when I said I could run "cave" games at fd 9, I meant the "cave" driver used for their 90s games like Donpachi. I can't run any cv1k games at speeds necessary for fd9, though I was only going by speed and I don't think I've bothered trying it out.
Hmm, with ddraw it seems OK. With D3D, not so much.
### DDRAW ###
ASIO: Game is running at 60.000000 Hz, screen at about 60.000000 Hz
ASIO: Driver kX ASIO initialized with latency 64,
sample rate 48000.00, compensated sample rate 48007.601563,
buffer size of 32768 samples
holdoff is 832 samples
Region ':maincpu' created
Region ':game' created
Region ':ymz770' created
window_proc: WM_PAINT
window_proc: WM_PAINT:END
Starting Deathsmiles (2007/10/09 MASTER VER) ':'
(missing dependencies; rescheduling)
Starting SH-3 (big) ':maincpu'
Starting RTC-9701 ':eeprom'
Starting Serial Flash ':game'
Starting Video Screen ':screen'
Optional device 'finder_dummy_tag' not found
Starting palette ':palette'
Starting Speaker ':lspeaker'
(missing dependencies; rescheduling)
Starting Speaker ':rspeaker'
(missing dependencies; rescheduling)
Starting Yamaha YMZ770 ':ymz770'
Starting EP1C12 Blitter ':blitter'
Starting Deathsmiles (2007/10/09 MASTER VER) ':'
(missing dependencies; rescheduling)
Starting Speaker ':lspeaker'
Starting Speaker ':rspeaker'
Starting Deathsmiles (2007/10/09 MASTER VER) ':'
ASIO: QPC freq: 14318180
Average speed: 99.79% (121 seconds)
Switchres: restoring DALDTMCRTBCD320x240x0x60 - Modeline "320x240_60 1
5.64KHz 59.91Hz" 6.63 320 336 368 424 240 242 245 261 -hsync -vsync
ASIO: Average callback timeslice usage: 0.322818
ASIO: Overrun/underrun: 5/1
window_proc: WM_NCACTIVATE
blit_lock = TRUE
window_proc: WM_DESTROY
blit_lock = TRUE
C:\framedelaytset\vicosku>vmame64 -asio_cal_freq 48007.6 -asio_device
1 -video ddraw -frame_delay 9 deathsml -priority 1 -rompath y:\mame015
3\roms -v
### D3D ###
ASIO: Game is running at 60.000000 Hz, screen at about 60.000000 Hz
ASIO: Driver kX ASIO initialized with latency 64,
sample rate 48000.00, compensated sample rate 48007.601563,
buffer size of 32768 samples
holdoff is 832 samples
Region ':maincpu' created
Region ':game' created
Region ':ymz770' created
window_proc: WM_PAINT
window_proc: WM_PAINT:END
Starting Deathsmiles (2007/10/09 MASTER VER) ':'
(missing dependencies; rescheduling)
Starting SH-3 (big) ':maincpu'
Starting RTC-9701 ':eeprom'
Starting Serial Flash ':game'
Starting Video Screen ':screen'
Optional device 'finder_dummy_tag' not found
Starting palette ':palette'
Starting Speaker ':lspeaker'
(missing dependencies; rescheduling)
Starting Speaker ':rspeaker'
(missing dependencies; rescheduling)
Starting Yamaha YMZ770 ':ymz770'
Starting EP1C12 Blitter ':blitter'
Starting Deathsmiles (2007/10/09 MASTER VER) ':'
(missing dependencies; rescheduling)
Starting Speaker ':lspeaker'
Starting Speaker ':rspeaker'
Starting Deathsmiles (2007/10/09 MASTER VER) ':'
ASIO: QPC freq: 14318180
ASIO: Channel sync disparity 147 at about update 14025
Average speed: 99.42% (139 seconds)
Switchres: restoring DALDTMCRTBCD320x240x0x60 - Modeline "320x240_60 1
5.64KHz 59.91Hz" 6.63 320 336 368 424 240 242 245 261 -hsync -vsync
ASIO: Average callback timeslice usage: 0.312359
ASIO: Overrun/underrun: 238/64
window_proc: WM_NCACTIVATE
blit_lock = TRUE
window_proc: WM_DESTROY
blit_lock = TRUE
C:\framedelaytset\vicosku>vmame64 -asio_cal_freq 48007.6 -asio_device
1 -video d3d -frame_delay 9 deathsml -priority 1 -rompath y:\mame0153\
roms -v
EDIT: Why this is, I don't know. I suppose it shouldn't work, since in-game speeds oscillate wildly between 200% -> 1500%.
EDIT AGAIN:
I'm actually getting terrible performance with this game with frame_delay 0 and d3d. (ASIO: Overrun/underrun: 899/163)
And roughly the same with d3d + frame_delay 9 (ASIO: Overrun/underrun: 709/324)
Although, with ddraw + frame_delay 0 (ASIO: Overrun/underrun: 1/0)
and ddraw + frame_delay 9 (ASIO: Overrun/underrun: 6/1)
I'm doing 180 second tests with the following parameters -frame_delay 0/9 -asio_holdoff 832 -asio_log -video ddraw/d3d -seconds_to_run 180 -autorol -nodisable_nagscreen_patch -nodisable_loading_patch -nosleep -priority 1
-
Weird! My results are sort of similar, but not as good. Here are my results with the switches you posted.
deathsml ddraw + frame delay 9 - ASIO: Overrun/underrun: 206/10
It's playable without any noticeable issues, except for an occasional obvious burst of overruns. None of the other games I've tried allow stable frame_delay 9 performance for any amount of time with either d3d or ddraw if I'm not over 2000% speed. Deathsml is a mess at frame_delay 9 and d3d, as I'd expect.
Direct Draw's behavior with frame_delay seems a bit unpredictable regarding both audio performance and input latency. I'd like to get a comparison of input lag between d3d and ddraw at various frame_delays in this game, but pressing f2 doesn't give me a nice test screen like with other games. I tried to use the character select screen to test, but in videos it's difficult to see when input is registered. I'll have to try something else later.
-
My understanding of this is that drawing a new frame with ddraw+vsync takes a nearly constant amount time (even if longer than d3d), however with d3d+vsync it takes a much more variable amount of time to render a frame. And this difference must be impacting the stability required for ASIO audio computations, while it's not so relevant at the scale we normally need for GroovyMAME.
-
Thanks, Calamity. That's a simple and sensible explanation.
-
I broke out the PS eye camera today to do some tests on DeathSmiles and frame_delay with DirectDraw.
Using frame_delay 9 + ddraw with this game does not seem to make any discernable difference compared to using fd 0.
I counted as follows, frame 0 is when the LED lights up. Frame n is when the game has shifted from the left image in the attachment (measure.jpg) to the right one.
frame [0] | frame [1 ... n-1] | frame [n]
input sent | delay | output on screen
so for a value of 4, it means the following
[0] | [1] [2] [3] | [4]
sent | .. delay .. | output on screen
fd 0 asio
4, 4, 5, 5, 4, 4, 4, 5, 4, 4, 4, 4, 5, 4, 4, 4, 4, 4, 5, 4, 4, 4, 5, 4, 4, 4
20 4's
6 5's
fd 9 asio
4, 4, 5, 5, 4, 4, 4, 5, 4, 4, 4, 4, 4, 4, 4, 4, 4, 5, 5, 4, 4, 4, 5, 4, 4, 4
20 4's
6 5's
fd 9 vanilla
4, 4, 4, 5, 4, 4, 4, 4, 4, 4, 4, 4, 4, 5, 4, 4, 4, 5, 5, 4, 4, 4, 5, 4, 4, 4
21 4's
5 5's
If anyone wants me to post the videos, I will do so.
-
DeathSmiles reacts to input 3 frames after you actually press a key, you can check this with the shift+P method. Relative to your counting it should be frame number [3].
Assuming a decent PC (one that can run this game unthrottled around 1000%) and using frame_delay 9, you should be seeing the game react at frame [3] for some of your samples at least.
I can think of some reasons you might be getting a worse result:
- The frame_delay option only works if -syncrefresh is enabled too. Maybe some ini file might be forcing it disabled? Get a log to check it. Remind the condition is:
if (m_framedelay != 0 && m_framedelay < 10 && m_syncrefresh && mode->hactive)
- If the input device is too slow, its own latency could be eating any gain obtained by the frame_delay feature. You can make sure this is not the case by means of the test screen of sf2 which is known to react in the very next frame.
- The cpu takes too long to emulate each frame, which I don't think is the case, otherwise you couldn't be using fd 9 fluently.
-
DeathSmiles reacts to input 3 frames after you actually press a key, you can check this with the shift+P method. Relative to your counting it should be frame number [3].
Assuming a decent PC (one that can run this game unthrottled around 1000%) and using frame_delay 9, you should be seeing the game react at frame [3] for some of your samples at least.
I can think of some reasons you might be getting a worse result:
- The frame_delay option only works if -syncrefresh is enabled too. Maybe some ini file might be forcing it disabled? Get a log to check it. Remind the condition is:
if (m_framedelay != 0 && m_framedelay < 10 && m_syncrefresh && mode->hactive)
- If the input device is too slow, its own latency could be eating any gain obtained by the frame_delay feature. You can make sure this is not the case by means of the test screen of sf2 which is known to react in the very next frame.
- The cpu takes too long to emulate each frame, which I don't think is the case, otherwise you couldn't be using fd 9 fluently.
Thanks for the info! I tried sf2 and managed to get next frame input response (which is damned awesome to see btw :) ), so I'm pretty sure the rig works as intended (it's a Teensy configured as USB keyboard, which alternates between pressing left/right when the LED lights up/goes out).
I'm not sure the rig is able to run the game at 1000%, a -bench 180 gives 570%, but when running the game, it seems fine at 100% with fd9, which seems strange.
The linked video (can be opened with VirtualDub with ffdshow installed) is a run with fd 9 + d3d with vanilla GM, beginning with sf2. Sf2 shows that input can be registered to appear at the next frame (starting at about 35 seconds in). I then chose 'Select new machine' and started deathsml, but I cannot get next frame (third frame) input registration. Could it be because the rig is simply not able to actually run it fast enough? Although it does seem strange it seems to run at 100%.
http://www.mediafire.com/watch/ivrss4u4smi6de7/cap-mjpg.avi (http://www.mediafire.com/watch/ivrss4u4smi6de7/cap-mjpg.avi)
-
Today I noticed something interesting. I recorded sf2 on my Core2Duo with fd 9 and couldn't seem to get next frame input response. I knew it should be capable because I've seen it in the past but for some reason it didn't work today. Tried -priority 1, -nosleep, increasing usb polling rate, all to no avail. I pressed f12 to see unthrottled speed and it was 700-800%, less than I had assumed for this game. Then I lowered fd to 7 and, finally, I could see input in next frame in my recording. I almost sure this has been the key factor, but as it often happens, after too many tests it gets a bit confusing. So it might turn out that using a too high value of fd is counter-productive.
-
Today I noticed something interesting. I recorded sf2 on my Core2Duo with fd 9 and couldn't seem to get next frame input response. I knew it should be capable because I've seen it in the past but for some reason it didn't work today. Tried -priority 1, -nosleep, increasing usb polling rate, all to no avail. I pressed f12 to see unthrottled speed and it was 700-800%, less than I had assumed for this game. Then I lowered fd to 7 and, finally, I could see input in next frame in my recording. I almost sure this has been the key factor, but as it often happens, after too many tests it gets a bit confusing. So it might turn out that using a too high value of fd is counter-productive.
Thanks for the quick reply!
This must be what's happening. From now on, I will make doubly sure the rig is actually capable of running the game at 1000%+ speeds when using fd 9, for expected operation.
-
Hi intealls,
Many thanks for creating your ASIO patch for GroovyMAME and trying to nail it to perfection. All of your work is -greatly- appreciated. I hope this will become part of the default GroovyMAME distribution.
From my first impressions it's working really well in many cases, audio latency is close to perfect. I can also confirm some of your and vicosku earlier findings, that there is (or seems to be) a difference in stability when running in ddraw vs d3d, and a variation in how low a buffer can be set for various drivers.
I've been reading much of the test results in this thread with great interest. With regards to possible unstable results for high framedelay values, I also wanted to share some thoughts that popped into my mind.
1. Haze once said that frame rendering time can be pretty variable within a single driver.
I.e. even with a high unthrottled speed for a single driver, if you start to look at the individual frame rendering times, they show a lot of variation. Just imagine it as being that unthrottled speed of a driver is 1000%, but some frames render at double of that and other at half of that (or even worse variation...)
For framedelay, knowing unthrottled speed is thus not enough. It's only an average of the quick and the slowly rendered frames. What we actually would need to know is the rendering time of the frames that took the most time in the unthrottled speed test. For example it should spit out an extra statistic besides the unthrottled speed. For example the time of the slowest 1 percentile frames rendered. That would create a much better math to base the maximum frame_delay value on.
2. We're not conscious enough of the impact of jitter and microstutter, which causes infrequent hick-ups in the video rendering pipeline.
There's an incredible amount of debate on this topic, but I'll just pick one which has some nice graphs in there to illustrate the issue:
Analysing Stutter – Mining More from Percentiles (https://developer.nvidia.com/content/analysing-stutter-%E2%80%93-mining-more-percentiles-0)
Interestingly it has some code at the bottom of the page to create the percentile pictures from raw FRAPS dumps. Apparently FRAPS logs the time beween Present() calls. Search google images for "fraps microstutter" and the issues becomes apparent quite quickly also.
I'm glad that Calamity posted his results, where he mentions how setting a too high value of fd can be counter-productive. Back when I did a lot of testing on framedelay my findings led me to the conclusion that regardless of very high values of unthrottled speed for a driver, if you ran it long enough, a very high framedelay value would cause issues. To quote from a thread back then:
Do take notice that there'll be individual frames that take much higher than the average. You don't want those frames to be skipping when setting the frame_delay to a too high value. "Wait" command on PC can also sometimes take longer than the wait value itself. Both combined are basicly the reason for the safety margin that the rule of thumb also accounts for. So even if your games run really really fast unthrottled (2000%+) , I would advise against setting it to a value higher than 8. What if you set it too high? Then it will be randomly starting to miss vertical blank for frames. You'll notice this by irregular video, audio and/or -added- input delay instead of lowered input delay.
Currently I think that 1. and 2. mentioned above may be a cause of "random" issues with audio buffer over- and underruns at tight latency and issues with high framedelay values. Possibly 2. is worse for D3D than it is for ddraw.
I guess the analogy is that by setting very tight latency on both audio and input response (high framedelay), it's like driving a rocket powered bicycle. It works as long as the road is straight, but it doesn't allow for any bends. With 1. and 2. in place I tend to think we're not driving that straight road.
But, ofcourse, we would need evidence on 1. and 2. in the groovymame context before coming to conclusions.
Regardless of this, thanks again for your work on this patch, it's a real joy to run GM with such low audio latency :)
-
Hi intealls,
Many thanks for creating your ASIO patch for GroovyMAME and trying to nail it to perfection. All of your work is -greatly- appreciated. I hope this will become part of the default GroovyMAME distribution.
Thanks :) Currently, the ASIO stuff makes GM tricky to build, and with the changes done to the sound system in MAME, some aspects are suboptimal from a code standpoint. Looking ahead, I think the right way to go about low latency audio is to do a native WASAPI implementation.
From my first impressions it's working really well in many cases, audio latency is close to perfect. I can also confirm some of your and vicosku earlier findings, that there is (or seems to be) a difference in stability when running in ddraw vs d3d, and a variation in how low a buffer can be set for various drivers.
I've been reading much of the test results in this thread with great interest. With regards to possible unstable results for high framedelay values, I also wanted to share some thoughts that popped into my mind.
1. Haze once said that frame rendering time can be pretty variable within a single driver.
I.e. even with a high unthrottled speed for a single driver, if you start to look at the individual frame rendering times, they show a lot of variation. Just imagine it as being that unthrottled speed of a driver is 1000%, but some frames render at double of that and other at half of that (or even worse variation...)
For framedelay, knowing unthrottled speed is thus not enough. It's only an average of the quick and the slowly rendered frames. What we actually would need to know is the rendering time of the frames that took the most time in the unthrottled speed test. For example it should spit out an extra statistic besides the unthrottled speed. For example the time of the slowest 1 percentile frames rendered. That would create a much better math to base the maximum frame_delay value on.
2. We're not conscious enough of the impact of jitter and microstutter, which causes infrequent hick-ups in the video rendering pipeline.
There's an incredible amount of debate on this topic, but I'll just pick one which has some nice graphs in there to illustrate the issue:
Analysing Stutter – Mining More from Percentiles (https://developer.nvidia.com/content/analysing-stutter-%E2%80%93-mining-more-percentiles-0)
Interestingly it has some code at the bottom of the page to create the percentile pictures from raw FRAPS dumps. Apparently FRAPS logs the time beween Present() calls. Search google images for "fraps microstutter" and the issues becomes apparent quite quickly also.
I'm glad that Calamity posted his results, where he mentions how setting a too high value of fd can be counter-productive. Back when I did a lot of testing on framedelay my findings led me to the conclusion that regardless of very high values of unthrottled speed for a driver, if you ran it long enough, a very high framedelay value would cause issues. To quote from a thread back then:
Do take notice that there'll be individual frames that take much higher than the average. You don't want those frames to be skipping when setting the frame_delay to a too high value. "Wait" command on PC can also sometimes take longer than the wait value itself. Both combined are basicly the reason for the safety margin that the rule of thumb also accounts for. So even if your games run really really fast unthrottled (2000%+) , I would advise against setting it to a value higher than 8. What if you set it too high? Then it will be randomly starting to miss vertical blank for frames. You'll notice this by irregular video, audio and/or -added- input delay instead of lowered input delay.
Currently I think that 1. and 2. mentioned above may be a cause of "random" issues with audio buffer over- and underruns at tight latency and issues with high framedelay values. Possibly 2. is worse for D3D than it is for ddraw.
I guess the analogy is that by setting very tight latency on both audio and input response (high framedelay), it's like driving a rocket powered bicycle. It works as long as the road is straight, but it doesn't allow for any bends. With 1. and 2. in place I tend to think we're not driving that straight road.
But, ofcourse, we would need evidence on 1. and 2. in the groovymame context before coming to conclusions.
Regardless of this, thanks again for your work on this patch, it's a real joy to run GM with such low audio latency :)
Thanks for the info, I'll read the linked article more carefully. During development, I seem to remember that some games generated samples very regularly at a fixed interval, but some seemed to do so more irregularly. For instance, DeathSmiles seemed to generate samples at a less fixed interval than say CPS1. So I don't think that the game driver can be left out of the equation (at least for low latency audio), but this needs to be investigated more closely.
-
Very interesting posts. Perhaps I will reduce my frame_delay values for some games to allow for the variability Dr. Venom mentioned. I haven't done many input lag tests at values lower than 8 or 9. I might create a table using CPS1, CPS2, and Neo Geo games in order to have a reference at each frame_delay level. It will be nice to know what kind of compromises are being made when reducing this value. It'll take me some time though.
I just came by to comment on my Asus Xonar DG/DGX with UNi driver setup, in case anyone was considering them. After experimenting some more, I can say that these cards allow for somewhat better performance than my Realtek onboard sound with ASIO4ALL, but it's not as good as I would like. I put a 1st-gen Audigy with kx driver v3551 in my Core 2 Duo machine, and it's a bit better, despite this machine not having the ability to disable HPET. The kx driver allows for much more flexibility when configuring ASIO, however, which is really nice. I've ordered an Audigy RX to put in my newer machine. Hopefully it outperforms the Xonar DGX and will be a decently inexpensive PCI express solution for use with this patch. I'll report back once it arrives.
-
Thanks :) Currently, the ASIO stuff makes GM tricky to build, and with the changes done to the sound system in MAME, some aspects are suboptimal from a code standpoint. Looking ahead, I think the right way to go about low latency audio is to do a native WASAPI implementation.
That of course would be awesome :)
Thanks for the info, I'll read the linked article more carefully. During development, I seem to remember that some games generated samples very regularly at a fixed interval, but some seemed to do so more irregularly. For instance, DeathSmiles seemed to generate samples at a less fixed interval than say CPS1. So I don't think that the game driver can be left out of the equation (at least for low latency audio), but this needs to be investigated more closely.
The article mostly is about how to measure frametime variability. I always wanted to get more data on this in mame context, but unfortunately I simply lack the time currently to do much testing.
Since maybe you guys are interested in this also, I'll just mention a possible route to getting statistics on frame time variability.
If this would work in the groovymame context, then maybe it could provide us with additional information on:
- D3D versus DDRAW performance
- frametime variability with different mame drivers when using high values of fd (does it cause occasional skipping?)
Apparently FRAPS (http://www.fraps.com/) (registered version?) is able to measure and dump frametimes in a .csv format file. As said FRAPS measures the time between present() calls.
Then there's a tool called FRAFS (http://sourceforge.net/projects/frafsbenchview/files/), on which you apparently can just drop the CSV file and it will produce a nice chart, showing a graph of frametime, plus the fastest and longest frametimes. Something like this:
(http://www.vortez.net/articles_file/20615_time.png)
The FRAFS link http://sourceforge.net/projects/frafsbenchview/files/ (http://sourceforge.net/projects/frafsbenchview/files/) has a step by step guide how to set it up to do the frametime measurements.
This youtube video has a "how to", for what it's worth (turn down the volume, to avoid the horrible music in it): Frame times FRAPS/FRAFS "How to" -- kinda (https://www.youtube.com/watch?v=4BfFcwCcCsY)
And this article on Vortez.net provides some interesting reading background on microstutter and measurements (the picture posted here is from that article): GPU Reviews: Why Frame Time Analysis is important (http://www.vortez.net/articles_pages/frame_time_analysis,1.html)
@ Vicosku
Thanks for reporting on the audio cards, much appreciated. From what I understand a "good card" for our purpose may depend more on it having a fast, stable and reliable ASIO driver, then it is depending on the hardware itself. I've had horrible experiences with the Creative ASIO drivers in the past, but it may just have been my specific card/setup.
-
Thanks, Dr. Venom. Using FRAPS to look at frametimes is definitely something I'd like to play with when I have some time.
I have the Audigy RX installed using kX driver version 3552. It works just like my first gen Audigy. Unfortunately, performance is really no better than the Xonar DGX for use with this patch, and perhaps a bit worse based on my initial testing. The main obvious benefit is that the kX ASIO driver allows for much finer sample size configuration compared to the Xonar Uni driver. The Uni driver only allows 1ms, 2ms, 4ms, 8ms, etc...I'll probably stick with 1ms though and adjust the intermediary buffer on a per-game basis when needed, so the extra control may be of limited use to me.
I've attached some batool logs of 9 passes at 900 seconds and then 30 minute tests of sfiii3 with asio_holdoff 1536. For the Audigy RX, the largest variation in frequency stability was .117 Hz. For the Xonar DGX, it was .089. I admit that the RX test was done using a value from a shorter calibration of 4 passes at 90 seconds each. This short calibration value used for the test was 47999.375000 versus the long calibration value of 47999.365835972.
Audigy RX - ASIO: Overrun/underrun: 122/56
Xonar DGX - ASIO: Overrun/underrun: 108/51
-
Hi Dr. Venom, nice to see you back.
Some quick notes:
- It's a well known fact that certain systems have very variable emulation time per frame, this is documented here (http://git.redump.net/mame/tree/src/emu/video.c):
* some games have very uneven frame rates; one frame will take
a long time to emulate, and the next frame may be very fast
(I'd say using "frame rate" in that context is a bit of an anachronism)
- With regards to D3D and the differences in rendering time per frame. Well, theoretically the "rendering" time with D3D *should* be as deterministic as Direct Draw is. I mean that the "present" call is, according to Microsoft just a flip operation, which simply means changing a memory pointer. So if we believe Microsoft here, it should have zero overhead, but for the required v-sync wait. There is one problem however, the "endscene" call actually returns before the gpu has finished, so when you call "present" probably the gpu still has work pending before it can flip, thus the time it takes.
- But anyway the biggst problem is the hack we use to bypass the frame queue arranged by the ATI drivers when using D3D. If only we got rid of that hack and use SetMaximumFrameLatency instead as suggested by koopah here: http://forum.arcadecontrols.com/index.php/topic,133194.msg1494962.html#msg1494962 (http://forum.arcadecontrols.com/index.php/topic,133194.msg1494962.html#msg1494962)
Maybe it would be as stable as DDraw is. The catch is it will only work from Vista on. To remove the hack, in src\osd\modules\render\drawd3d.c:
m_presentation.PresentationInterval = ((video_config.triplebuf && window().fullscreen()) || video_config.waitvsync || video_config.syncrefresh))?
D3DPRESENT_INTERVAL_ONE : D3DPRESENT_INTERVAL_IMMEDIATE;
/*
// sync to VBLANK
if (window().machine().options().frame_delay() != 0 && ((video_config.triplebuf && window().fullscreen()) || video_config.waitvsync || video_config.syncrefresh))
{
D3DRASTER_STATUS raster_status;
memset (&raster_status, 0, sizeof(D3DRASTER_STATUS));
while (!raster_status.InVBlank)
{
if ((*d3dintf->device.get_raster_status)(m_device, &raster_status) != D3D_OK)
break;
}
}
/*
-
Hi Calamity,
Thanks, good to be back. It's great to see all the work and testing done by you, intealls and vicosku, interesting and enjoyable stuff!
- It's a well known fact that certain systems have very variable emulation time per frame, this is documented here (http://git.redump.net/mame/tree/src/emu/video.c):
Ah, good to have confirmation from the source code documentation.
- But anyway the biggst problem is the hack we use to bypass the frame queue arranged by the ATI drivers when using D3D. If only we got rid of that hack and use SetMaximumFrameLatency instead as suggested by koopah here: http://forum.arcadecontrols.com/index.php/topic,133194.msg1494962.html#msg1494962 (http://forum.arcadecontrols.com/index.php/topic,133194.msg1494962.html#msg1494962)
I didn't realize that the get_raster_status hack possibly wouldn't be stable. From a discussion back then I remember a quote that it ticked like a swiss clock, so I sort of assumed it was working really well for D3D.
But definitely worth a try! If it would work more stable with SetMaximumFrameLatency, then it would quite possiby help the stability for ASIO as well.
Unfortunately I don't have a recent compilation environment set up. If you have a bit of time, would it be too much to ask for you to compile that version and post it here? I guess vicosku, intealls and maybe other users, would be very interested as well. Otherwise I'll get around to it, but just not as soon.
From what I read if you compile an executable with SetMaximumFrameLatency in the code (even when not calling it), then it will crash when run on XP. Just that we know that going forward it would require maintaining/releasing two seperate GM executables.
@ viscosku
Thanks, Dr. Venom. Using FRAPS to look at frametimes is definitely something I'd like to play with when I have some time.
That would be great, no real idea if it works, but at least it could provide some decent statistics on frame times. Especially on how well the higher fd values actually work, i.e. whether they cause occasional bouts of frameskipping (and thus delayed input latency...)
Good to know that the Xonar DGX and the Audigy are a bit on par with eachother.
The sfiii gaming test results had me wondered a little bit. The over and underruns you're showing are much to large for things working "properly", i.e accurate. Even if you run a game for half an hour, if everything is working ok, you should have very few over-/ underruns. It's also showing channel sync disparity in the logs. My personal opinion/guess is that your fd value is still to high, and you're sacrificing the emulation quality because of it. (But maybe that is your deliberate choice?) Do you get close to zero buffer over-/underruns when running with fd1?
-
Hi Dr. Venom, nice to see you back.
Some quick notes:
- It's a well known fact that certain systems have very variable emulation time per frame, this is documented here (http://git.redump.net/mame/tree/src/emu/video.c):
* some games have very uneven frame rates; one frame will take
a long time to emulate, and the next frame may be very fast
(I'd say using "frame rate" in that context is a bit of an anachronism)
- With regards to D3D and the differences in rendering time per frame. Well, theoretically the "rendering" time with D3D *should* be as deterministic as Direct Draw is. I mean that the "present" call is, according to Microsoft just a flip operation, which simply means changing a memory pointer. So if we believe Microsoft here, it should have zero overhead, but for the required v-sync wait. There is one problem however, the "endscene" call actually returns before the gpu has finished, so when you call "present" probably the gpu still has work pending before it can flip, thus the time it takes.
- But anyway the biggst problem is the hack we use to bypass the frame queue arranged by the ATI drivers when using D3D. If only we got rid of that hack and use SetMaximumFrameLatency instead as suggested by koopah here: http://forum.arcadecontrols.com/index.php/topic,133194.msg1494962.html#msg1494962 (http://forum.arcadecontrols.com/index.php/topic,133194.msg1494962.html#msg1494962)
Maybe it would be as stable as DDraw is. The catch is it will only work from Vista on. To remove the hack, in src\osd\modules\render\drawd3d.c:
m_presentation.PresentationInterval = ((video_config.triplebuf && window().fullscreen()) || video_config.waitvsync || video_config.syncrefresh))?
D3DPRESENT_INTERVAL_ONE : D3DPRESENT_INTERVAL_IMMEDIATE;
/*
// sync to VBLANK
if (window().machine().options().frame_delay() != 0 && ((video_config.triplebuf && window().fullscreen()) || video_config.waitvsync || video_config.syncrefresh))
{
D3DRASTER_STATUS raster_status;
memset (&raster_status, 0, sizeof(D3DRASTER_STATUS));
while (!raster_status.InVBlank)
{
if ((*d3dintf->device.get_raster_status)(m_device, &raster_status) != D3D_OK)
break;
}
}
/*
The hack should be a GroovyMAME option IMO. XP is finished. New motherboards don't even have drivers for it anymore. With super resolutions, isn't there basically no downside to using Windows 7 now?
-
Unfortunately I don't have a recent compilation environment set up. If you have a bit of time, would it be too much to ask for you to compile that version and post it here? I guess vicosku, intealls and maybe other users, would be very interested as well. Otherwise I'll get around to it, but just not as soon.
I would certainly appreciate this.
The sfiii gaming test results had me wondered a little bit. The over and underruns you're showing are much to large for things working "properly", i.e accurate. Even if you run a game for half an hour, if everything is working ok, you should have very few over-/ underruns. It's also showing channel sync disparity in the logs. My personal opinion/guess is that your fd value is still to high, and you're sacrificing the emulation quality because of it. (But maybe that is your deliberate choice?) Do you get close to zero buffer over-/underruns when running with fd1?
Yes, sfiii has been frustrating me for the past year, ever since reading your first audio latency posts. I can use the ASIO patch and get almost no over and underruns in CPS1, CPS2, and Neo Geo games with very low latencies. sfiii just gives me a lot of trouble in particular, even with asio_holdoff set to 1536 or 2048. Changing ASIO latency from 96 to 192 reduced the overruns/underruns to 72/50 over 30 minutes with three channel sync disparities, which obviously isn't as low as I would like. I'm still trying to decide where I want to compromise with this game. I've tried frame_delay 7 with basically no improvement, but I just ran with frame_delay 1 at your suggestion. It gave me 99/49 with 6 disparities. The game fluctuates between 950%-1100% unthrottled in gameplay, and shoots up to 2000% in between rounds and stage transitions. These are the points when you can most obviously hear the audio issues, if they occur.
-
I decided to test with direct draw again. I can run for 30 minutes with zero issues with an ASIO latency of 96 and the following settings in sfiii3:
-video ddraw -asio_holdoff 1152 -frame_delay 1
I also checked the input lag. I counted the first 20 samples in the video, and every single one reflected input on the 2nd frame after it was entered. I still can't produce any evidence that it's possible to get next-frame response with ddraw in Windows 7. However, I think these are the settings I will stick with this game, and most others. Perhaps consistent 2nd-frame response is preferable to getting next-frame response 50% of the time anyway.
Also, with CPS2 games, I can run with the same settings and asio_holdoff 832 for 30 minutes and only get 16 underruns. Very nice. It will be interesting to see how d3d compares with the change that was mentioned. sfa3 was actually the game that prompted me to reduce all the way to fd 1, because severe audio issues occurred with higher values when asio_holdoff was set to 832. Since I get consistent 2nd frame response with FD 1 in both CPS2 and CPS3 games and can't get next-frame ddraw response even at fd9, using a higher setting than 1 seems pointless. Of course, this contrasts with what we've seen with d3d so far, where it seems that using as high of an fd value as possible before issues occur is ideal.
-
Sorry for a 3rd post in a row, but I just wanted to share some more of my direct draw results. CPS1 tests give me a 3rd frame input result rarely when input was received at the very end of a frame. CPS2 and CPS3 may be the same, but I didn't see any 3rd frame results in the samples I counted for those. I can use frame_delay 8 in CPS1/2 only if I increase asio_holdoff to 1536 to eliminate sound issues, but I don't think I'm going to bother. It feels good at frame_delay 1.
I also tested Neo Geo, which gave me more pronounced differences. Frame Delay 1 allows input to be shown on the third frame 50% of the time. Frame delay 8 reduced this to 1/20 samples, while still allowing for perfect audio at ASIO 96 asio_holdoff 832, unlike CPS1/2/3. I'd also like to reiterate that I don't achieve next-frame input results with d3d in Neo Geo games either. All these settings really have to be evaluated on a per-game, or at least per-driver, basis.
-
Hi everyone, and sorry the late reply, been real busy lately. I removed the hack mentioned in the above post, and I've uploaded it to here: http://www.mediafire.com/download/9vuzpvsz8vg9u88/gmame162-asio-hack_removed.zip (http://www.mediafire.com/download/9vuzpvsz8vg9u88/gmame162-asio-hack_removed.zip)
I'm unsure if I need to change anything in the first code chunk (PresentationInterval), so that's left as is.
Edit: realized that more changes were needed, aside from just commenting out the snippet posted.
I should put together an updated diff so others can experiment with the ASIO stuff as well. Might put together a short tutorial how to get started with building with MSVC, could use a refresher myself.
vicosku: Thanks again for your tests, I'll read them more thoroughly the next few days.
-
Hi intealls,
Is MSVC strictly required? Wouldn't it be possible to compile it with MinGW without major changes?
-
Last time I tried, I was unable to build because of BASSASIO. But I'll give it a shot again, and report how it goes.
-
Hi intealls,
Is MSVC strictly required? Wouldn't it be possible to compile it with MinGW without major changes?
Good news! It builds (both 32 and 64-bit). The last time I tried was at 0.156, and luckily lots have happened since then.
I'll have a patch ready sometime later tonight.
-
I'll have a patch ready sometime later tonight.
Great news! I'm greatly looking forward to testing the patch. I'm having a bunch of people over this weekend and am excited to show off GroovyMAME in the best light possible.
-
I'll have a patch ready sometime later tonight.
Great news! I'm greatly looking forward to testing the patch. I'm having a bunch of people over this weekend and am excited to show off GroovyMAME in the best light possible.
Actually, MSVC seems to produce slightly faster builds. Building with MinGW is purely for convenience, since setting up MSVC can be quite a hassle.
-
If you're using a newer version of the MAME build tools, you'll need to pacman -S the following packages:
mingw64/mingw-w64-x86_64-tools-git
msys/patch
Instructions:
download http://uk.un4seen.com/files/bassasio13.zip (http://uk.un4seen.com/files/bassasio13.zip)
unzip mame sources
unzip bassasio13.zip in [extracted root dir]\bassasio
start buildtools
go to root dir
run fix_bassasio_mingw.bat
if building for GM:
patch -p0 -E < hi_[ver].diff
patch -p0 -E < [ver]_groovymame_015x.diff
patch -p1 -E < asio_[ver]_gm.txt
make CPPFLAGS=-DGM -j[n], where n is the number of workers you want, usually number of CPUs + 1
if building for vanilla:
patch -p1 -E < asio_[ver]_mainline.txt
then make as you usually do
copy the right BASSASIO.dll to the root folder (32 = bassasio\bassasio.dll / 64 = bassasio\x64\bassasio.dll) and go
See the first post http://forum.arcadecontrols.com/index.php/topic,142143.0.html (http://forum.arcadecontrols.com/index.php/topic,142143.0.html) for the link to the latest patch
-
Hi intealls,
Great work, thanks for this, and very good news it can be compiled with MinGW. Compared with your old patch I've noticed you no longer modify some of the Switchres files (modeline.c, etc). I was curious about this at the time. Hopefully I have some time during the next weeks to test this combined with the patch I mentioned above (remove the frame queue patch and use d3d 9ex.)
-
Yes, thanks again, Intealls!
Calamity, I've compiled a binary with this patch and your suggested d3d changes. I had to fix a couple of typos with the code you posted. This is basically my first time doing this, so hopefully I haven't made any mistakes. I won't be able to test until late tonight, but here it is, along with the code I used in drawd3d.c
Link removed. Not properly built.
I assume you meant to comment this section out, so I used */ instead of /* at the end based on what notepad++ was telling me.
/*
// sync to VBLANK
if (window().machine().options().frame_delay() != 0 && ((video_config.triplebuf && window().fullscreen()) || video_config.waitvsync || video_config.syncrefresh))
{
D3DRASTER_STATUS raster_status;
memset (&raster_status, 0, sizeof(D3DRASTER_STATUS));
while (!raster_status.InVBlank)
{
if ((*d3dintf->device.get_raster_status)(m_device, &raster_status) != D3D_OK)
break;
}
}
*/
I couldn't get what you posted to allow compilation, so I just pulled this from the unpatched file. I assume it was just forum formatting causing the problem. This is what I used.
m_presentation.PresentationInterval = ((video_config.triplebuf && window().fullscreen()) ||
video_config.waitvsync || video_config.syncrefresh) ?
D3DPRESENT_INTERVAL_ONE : D3DPRESENT_INTERVAL_IMMEDIATE;
-
Yes, sorry for that, I didn't test the code. However that needs to be combined with the Direct3D 9ex link added in the same post, otherwise you'll be getting several frames of added lag due to the frame queue.
-
Ah, Koopah's stuff, right? Sorry, I missed that. Okay, I'll give it a try.
-
Problem is, there's not a diff but the actual modified files, so you need to compare those to codebase from February to figure out the changes.
-
Hah, I knew it couldn't be as easy as I thought. Okay, I'll give it a shot. Whether I succeed or discover it's beyond me, I'll post an update. Maybe Intealls or someone else will beat me to it though.
-
I think I have it. D3D with Frame Delay 0 in sfiii3 with regular GroovyMAME typically gives me input results on the 5th or 6th frame. With Koopah's changes, I get consistent results on the 3rd frame, which is basically what I get with ddraw and frame_delay 0. So, I think I got at least part of these changes right. Also, I can now use frame_delay 8 in sfiii3 with only 1 overrun in 30 minutes with the same settings that produced over 100 before.
However, frame_delay seems to have no effect now. I get 3rd frame results with frame_delay 8 where I got 1st and 2nd frame results without these changes. I hope I've done something wrong. I think this is far as I can go for now. I'll leave it to the pros from here. I'll share what I've done in case it's helpful in any way, along with the resulting binary.
I first tried to copy Koopah's changes from the .158 to .162 source, and then performed the process outlined by Intealls, along with the addition of the changes suggested by Calamity. The only part that tripped me up was some sort of change in drawd3d.c regarding"d3d::renderer::get_primitives();" from .158 to .162. I tried what I figured the new value should be. I had little idea what I was doing, so it's likely I didn't edit this part correctly.
ddrawd3d.c (http://pastebin.com/gBqREWwF)
d3d9intf.c (http://pastebin.com/wY0T0u4k)
Build (https://mega.co.nz/#!KdETRDQT!1jH0l6WuJ6a1QAw_GX6MnjbvqxanOji8ujb43UbAx70)
-
I think I have it. D3D with Frame Delay 0 in sfiii3 with regular GroovyMAME typically gives me input results on the 5th or 6th frame. With Koopah's changes, I get consistent results on the 3rd frame, which is basically what I get with ddraw and frame_delay 0. So, I think I got at least part of these changes right. Also, I can now use frame_delay 8 in sfiii3 with only 1 overrun in 30 minutes with the same settings that produced over 100 before.
However, frame_delay seems to have no effect now. I get 3rd frame results with frame_delay 8 where I got 1st and 2nd frame results without these changes. I hope I've done something wrong. I think this is far as I can go for now. I'll leave it to the pros from here. I'll share what I've done in case it's helpful in any way, along with the resulting binary.
I first tried to copy Koopah's changes from the .158 to .162 source, and then performed the process outlined by Intealls, along with the addition of the changes suggested by Calamity. The only part that tripped me up was some sort of change in drawd3d.c regarding"d3d::renderer::get_primitives();" from .158 to .162. I tried what I figured the new value should be. I had little idea what I was doing, so it's likely I didn't edit this part correctly.
ddrawd3d.c (http://pastebin.com/gBqREWwF)
d3d9intf.c (http://pastebin.com/wY0T0u4k)
Build (https://mega.co.nz/#!KdETRDQT!1jH0l6WuJ6a1QAw_GX6MnjbvqxanOji8ujb43UbAx70)
Great job! I can't be of any help when it comes to D3D/frame_delay (aside from testing), but I look forward to see how this affects the audio sample generation.
-
Hope this version is still active. Any builds for MAME 0.162? I've never had much luck compiling GroovyMAME myself.
Thanks :)
-
Hope this version is still active. Any builds for MAME 0.162? I've never had much luck compiling GroovyMAME myself.
Thanks :)
Sure, here's 0.162 built with MSVC: http://www.mediafire.com/download/n2jyl6f773p530h/gmame162-asio.zip (http://www.mediafire.com/download/n2jyl6f773p530h/gmame162-asio.zip)
And here's 0.162 with koopah's D3D changes built with MinGW by vicosku. https://mega.co.nz/# (https://mega.co.nz/#)!KdETRDQT!1jH0l6WuJ6a1QAw_GX6MnjbvqxanOji8ujb43UbAx70
-
You're great, intealls! :)
Much appreciated. Going to get this going today!
Thanks again! :cheers:
Hope this version is still active. Any builds for MAME 0.162? I've never had much luck compiling GroovyMAME myself.
Thanks :)
Sure, here's 0.162 built with MSVC: http://www.mediafire.com/download/n2jyl6f773p530h/gmame162-asio.zip (http://www.mediafire.com/download/n2jyl6f773p530h/gmame162-asio.zip)
And here's 0.162 with koopah's D3D changes built with MinGW by vicosku. https://mega.co.nz/# (https://mega.co.nz/#)!KdETRDQT!1jH0l6WuJ6a1QAw_GX6MnjbvqxanOji8ujb43UbAx70
-
And here's the patch!
Thanks! :)
I think I have it. D3D with Frame Delay 0 in sfiii3 with regular GroovyMAME typically gives me input results on the 5th or 6th frame. With Koopah's changes, I get consistent results on the 3rd frame, which is basically what I get with ddraw and frame_delay 0. So, I think I got at least part of these changes right. Also, I can now use frame_delay 8 in sfiii3 with only 1 overrun in 30 minutes with the same settings that produced over 100 before.
However, frame_delay seems to have no effect now. I get 3rd frame results with frame_delay 8 where I got 1st and 2nd frame results without these changes. I hope I've done something wrong. I think this is far as I can go for now. I'll leave it to the pros from here. I'll share what I've done in case it's helpful in any way, along with the resulting binary.
Thanks vicosku for your work, it's promising that at least d3d with frame_delay disabled works better than regular groovymame with framedelay disabled.
Too bad the framedelay now does not seem to work at all. This would also explain the sudden very low number of overruns on sfiii while using fd 8, i.e. it's actually not invoking framedelay thus being equivalent to fd 0 for sound stability.
Hopefully Calamity will find some time to run through the code and see what possibly may be wrong.
I decided to test with direct draw again. I can run for 30 minutes with zero issues with an ASIO latency of 96 and the following settings in sfiii3:
-video ddraw -asio_holdoff 1152 -frame_delay 1
I also checked the input lag. I counted the first 20 samples in the video, and every single one reflected input on the 2nd frame after it was entered. I still can't produce any evidence that it's possible to get next-frame response with ddraw in Windows 7. However, I think these are the settings I will stick with this game, and most others. Perhaps consistent 2nd-frame response is preferable to getting next-frame response 50% of the time anyway.
Also, with CPS2 games, I can run with the same settings and asio_holdoff 832 for 30 minutes and only get 16 underruns. Very nice. It will be interesting to see how d3d compares with the change that was mentioned. sfa3 was actually the game that prompted me to reduce all the way to fd 1, because severe audio issues occurred with higher values when asio_holdoff was set to 832. Since I get consistent 2nd frame response with FD 1 in both CPS2 and CPS3 games and can't get next-frame ddraw response even at fd9, using a higher setting than 1 seems pointless. Of course, this contrasts with what we've seen with d3d so far, where it seems that using as high of an fd value as possible before issues occur is ideal.
Thanks again for all the testing you've been doing. I'm intrigued by your findings (also posted about previously) that ddraw never seems to provide next frame response, even when using high values for framedelay. For some reason it seems that with ddraw another video buffer is created, or that it somehow blocks the input polling longer than d3d.
Would you be willing to do another test for ddraw (using regular groovymame), involving the radeonpro tool (http://www.radeonpro.info/download/ (http://www.radeonpro.info/download/))? Basicly I would like to force the flipqueuesize to 1 while using ddraw with regular groovymame and fd 7 to 9.
There is however a little trick involved, as the radeon pro tool cannot take hold of a program running in administrator mode (such as groovymame for win 7).
The trick is to use a "dummy" executable that is started before groovymame, and triggers the radeon pro profile. For example you could use Soft15Khz (http://files.arianchen.de/soft15khz/soft15khz.zip) as it just sits in the windows tray doing nothing. But if you add it to radeon pro it will trigger the radeon pro profile when started.
Could you test it this way, adding soft15khz to a radeonpro profile, and in this profile change flipqueuesize to 1 (found in the Advanced Tab (http://www.radeonpro.info/manual/contents/the-advanced-tab)), and disabling Aero (found in the Tweaks Tab (http://www.radeonpro.info/manual/contents/the-tweaks-tab)).
It's important that you also disable aero, as it will give a visual clue that Radeonpro is actually activating the profile when you start the dummy executable (soft15khz in this example). If you're going to do this test, please make double sure it's triggering the profile correctly, as radeon pro itself will give no clue that it's activated. If you include the disabling of Aero, you'll see Windows switching from Aero to non-Aero desktop as soon as the dummy executable is started.
Once you're sure that the dummy executable is triggering the radeonpro profile correctly you can then start regular groovymame with ddraw and a high framedelay value. I'm very curious whether forcing the FlipQueueSize of 1 will cause next frame responses to occur in your test for ddraw. It's a wild guess, but sometimes trying those may be worthwhile... :)
Of course when you're sure that manually everything is working as it should, you could create a little batch file to simplify things, for example (use your own paths):
Start Q:\Emulators\Soft15Khz\Quickres.exe
Timeout /T 1
start /min /wait mame.exe
taskkill /IM Quickres.exe
-
I've just tried "official" GM 0.162 with -video ddraw -fd 6, I do get next frame response here in XP. I did have to lower the -fd value with respect to d3d. Notice in my modest machine I can only get next frame response when input is registered during the first 1/3 of the previous frame.
https://www.dropbox.com/s/k6kj90npzi930x1/sf2_ddraw_fd_6.MOV?dl=0 (https://www.dropbox.com/s/k6kj90npzi930x1/sf2_ddraw_fd_6.MOV?dl=0)
-
Well I've created a diff to apply koopah's patch, this is better than having the whole source files and can be applied to future versions. It's meant to be applied after the groovymame diff (although the order might not matter).
I've created another diff, "fd_mod", this is experimental and an attempt to get next frame response with D3D9ex too. It will probably not do anything useful but it's worth a try. I've moved the manual wait for vertical blank *after* the present call*. This patch is to be applied after the koopah's one. I can't test it myself because my led-wired machine is still xp only.
I've uploaded a build for quick testing, this one does not include inteall's a asio patch, just plain GM with D3D9ex and the mod mentioned above:
https://www.dropbox.com/s/jv1jdk2cmgnce7z/mame64_d3d9ex.7z?dl=0 (https://www.dropbox.com/s/jv1jdk2cmgnce7z/mame64_d3d9ex.7z?dl=0)
* Instead from manually calling GetRasterStatus in a loop as we do now, I also tried the "new" WaitForVBlank method that exists since D3D9ex, but it's damned slow, at least for the Intel drivers I'm testing with, so I discarded it.
-
I've just tried "official" GM 0.162 with -video ddraw -fd 6, I do get next frame response here in XP.
That's great news! Was your test performed with sfiii (same as vicosku)?
It might be then that vicosku's results for ddraw are specific to Windows 7. I wouldn't be surprised if there's some humpty dumpty extra buffering going on with ddraw in Win 7, or not... we'll find out hopefully ;)
Would it be possible for you to do the same test in your Windows 7 machine?
Edit: I just see your other post that you have your LED setup only on your XP machine.. too bad.
-
Was your test performed with sfiii (same as vicosku)?
No, I tested sf2, I don't have the chd for sfiii3 in my cab. Anyway, any game that's known to react in the next frame is good for testing.
It might be then that vicosku's results for ddraw are specific to Windows 7. I wouldn't be surprised if there's some humpty dumpty extra buffering going on with ddraw in Win 7, or not... we'll find out hopefully ;)
ddraw is emulated to some extent in W7, probably through D3D, so maybe.
-
No, I tested sf2, I don't have the chd for sfiii3 in my cab. Anyway, any game that's known to react in the next frame is good for testing.
I see what you mean.
I think it would be better if we all would settle on one particular game for all testing though, just to be 100% sure we are comparing apples with apples.
It would not be the first time a specific driver gets some extra buffer implemented in the driver itself, making comparisons worthless. Would you agree? I would be fine with sf2 being that game though.
ddraw is emulated to some extent in W7, probably through D3D, so maybe.
*IF* this would be the case, I have a hunch that what I outlined in one of my previous posts, may do away with this extra delay.
I've uploaded a build for quick testing, this one does not include inteall's a asio patch, just plain GM with D3D9ex and the mod mentioned above:
https://www.dropbox.com/s/jv1jdk2cmgnce7z/mame64_d3d9ex.7z?dl=0 (https://www.dropbox.com/s/jv1jdk2cmgnce7z/mame64_d3d9ex.7z?dl=0)
A quick comment about this build, it seems it has an (the old?) issue with interlaced screens.
When I start Playstation Japan (driver "psj") it immediately complains with*:
Direct3D: Error 08760877 during device present call
I guess this is because PSJ starts with an interlaced screen? The regular GM 0.162 works without an issue with the same settings.
Maybe a silly question, but I see the log reporting "Direct3D: Using Direct3D 9", shouldn't this be reporting explicitly that Direct3D 9Ex is being used?
*Edit: I have interlaced enabled in the psj.ini
Edit 2: Indeed if I disable interlace in psj.ini ("interlace 0") then the issue does not occur. Just to be complete I have the following modeline for interlace in the config:
crt_range2 "15525-15780, 49.00-63.00, 3.556, 4.741, 7.111, 0.064, 0.160, 1.120, 0, 0, 0, 0, 448, 480"
-
This weekend is really busy for me, so I just have a quick reply for now.
Dr. Venom, I'm very interested in running the tests you described. It will likely be a few days until I can, however.
Calamity, that's excellent news the next frame response with DDRAW is possible. I may need to put XP on my secondary machine again, if only for testing. I loaded up official GM .162 in a completely fresh directory with ddraw and FD6. I still can't get next-frame response on Windows 7 on either of my machines. FD9 is the same.
Thank you for providing the diff and build with the D3D9ex changes so quickly! I tested sf2 on your fd_mod build with frame_delay 9 in a fresh directory and get next-frame response again! However, I didn't realize until reviewing the video that I still had ddraw set from the previous tests, and I am out of time to do more tests this morning. So far, it seems something about this build is allowing me to get next-frame response in Windows 7 with ddraw, unlike the current official build. I should be able to test d3d with this one tomorrow and post some videos.
*Edit - Please ignore lazy testing.
-
Awesome stuff here :)
To add further fuel to the confusing array of builds currently flying around this thread I applied the patches Calamity posted earlier to the ASIO build. It can be found here: http://www.mediafire.com/download/ra59b1etw50rst7/gmame162-asio-calamity-koopah.zip (http://www.mediafire.com/download/ra59b1etw50rst7/gmame162-asio-calamity-koopah.zip)
However, currently, it seems sensible that all purely frame-delay related tests should be performed against vanilla!
-
Thanks, Intealls! I'll test this too. I hope you don't mind all this input delay discussion in your thread. I think we all are in search of the same thing - lowest possible input response while using your patch to achieve perfect audio. I took some time this morning to properly organize my input delay test results for use as reference in further discussion. I've left the ASIO patch out of the results for now, though my earlier testing gives me confidence that it is not responsible for significant input delays.
Calamity, I'm sorry, you can get next-frame response with ddraw in Windows 7 with official GM .162. I didn't count enough samples before. However, based on several tests, I cannot approach the next-frame response percentage I get with d3d in official GM with frame_delay 9, which is now nearly 75%. DDraw gives me about 25% out of 40 samples among two tests (1 official, 1 d3d9ex_fd_mod).
Here are links to videos of 6 different tests and a spreadsheet counting the first 20 responses from each. Unfortunately, the D3D9ex/FD_mod build did not allow next-frame response on any of the 40 samples I counted (half fd6, half fd9). Most were 2nd frame though, which is better than the 3rd frame results my sketchy build produced.
Spreadsheet (https://docs.google.com/spreadsheets/d/1w0mM7tOURkyh82V0F2CVGRAUMASurFInRyT4ZD1NazQ/edit?usp=sharing)
official .162 ddraw fd9
(https://mega.co.nz/#!aVMXHAQT!RGJF-1ipN9W-JMYPp8aHi2zZcvZioqBnC5IGVcBungw)official .162 d3d fd9
(https://mega.co.nz/#!eBFCVQDQ!5Q5R-jhXcdUMS7g6NaIYYtsK1_WiIBQa2ryjAEKkROM)d3d9ex_fdmod_Ddraw FD9
(https://mega.co.nz/#!SQ1l0DRS!pihm8Ng5fLqv7nTXc7f5WClanfDFb_L8_OXG0VA5icY)d3d9ex_fdmod_Ddraw FD1
(https://mega.co.nz/#!3Mt03JiC!3cB7EgoBgKL1tR86l9ciJXhoxpK9yqWoKB7ULbfHJJY)d3d9ex_fdmod_fd6 (https://mega.co.nz/#!TRsRhKKJ!8t_AzyRN53uFU5LIzMilTWQ6Us7RNauKO9Q6g9dYbnk)
d3d9ex_fdmod_fd9 (https://mega.co.nz/#!yI1gkZgb!1LlhyciYeSPQ2UOzHYMi31dPDOCteH0a9dOiujfRgEs)
*edit - Formatting.
-
Thanks, Intealls! I'll test this too. I hope you don't mind all this input delay discussion in your thread. I think we all are in search of the same thing - lowest possible input response while using your patch to achieve perfect audio.
I certainly don't mind, you're absolutely right. :) It was frame delay that triggered me to start developing the ASIO patch.
Also, if you're using the ASIO build and want to know more about how a game performs, as well as more info about sample generation and under-/overruns, you can use the attached Octave script. I found it extremely useful when testing various frame delay settings.
Octave can be downloaded from here: ftp://ftp.gnu.org/gnu/octave/windows/octave-4.0.0_0-installer.exe (http://ftp://ftp.gnu.org/gnu/octave/windows/octave-4.0.0_0-installer.exe)
Simply download l.txt and rename it to l.m. Run the game with -asio_log set, then start Octave, browse to the folder you placed l.m in in the top left file browser pane, and issue l('path to asio.log')', e.g. if asio.log is placed in c:\asio.log, you should issue l('c:\asio.log'). You should receive four nice graphs detailing emulation speed, as well as information about the number of samples in the left/right channel. The fd9 example picture shows bad results, the fd8 example picture shows OK results. Ideally, all the plots should be straight (like the first ~8000 samples in the fd8 example).
-
Vicosku, thanks a lot for your tests.
It's a relief to see that ddraw still works as supposed. Knowing the code in there, it was hard to explain that any hypothetical frame queue could be causing that. The worse result compared to d3d is expectable if ddraw stalls longer than d3d. Having that clear, I'd recommend that we focus on d3d because ddraw is dead and it won't even work with W8/10. I see moving to D3D9ex or higher an attempt to make ddraw absolutely unnecessary as we are not going to have it available anymore.
It's certainly a big disappointment that D3D9ex doesn't allow next frame response out of the box. This will require either to stick with hacks by now, which make the timing unstable for something like asio to work properly, or rennounce to next frame response. I have a theory of what could be happening with D3D9ex, it'd be good to confirm that D3D9ex *without* the fd_mod diff actually lags a frame more (in other words, that the fd_mod actually does something).
-
Great stuff guys, loving it!! :)
Also, if you're using the ASIO build and want to know more about how a game performs, as well as more info about sample generation and under-/overruns, you can use the attached Octave script. I found it extremely useful when testing various frame delay settings.
Thanks for pointing this out. I look forward to running some of these analyses myself, and reporting back course!
Calamity, I'm sorry, you can get next-frame response with ddraw in Windows 7 with official GM .162. I didn't count enough samples before. However, based on several tests, I cannot approach the next-frame response percentage I get with d3d in official GM with frame_delay 9, which is now nearly 75%. DDraw gives me about 25% out of 40 samples among two tests (1 official, 1 d3d9ex_fd_mod).
Here are links to videos of 6 different tests and a spreadsheet counting the first 20 responses from each. Unfortunately, the D3D9ex/FD_mod build did not allow next-frame response on any of the 40 samples I counted (half fd6, half fd9). Most were 2nd frame though, which is better than the 3rd frame results my sketchy build produced.
Thanks for your relentless testing, awesome to get to the bottom of this :)
Dr. Venom, I'm very interested in running the tests you described. It will likely be a few days until I can, however.
Hopefully you have some time left to do a test while forcing the FlipQueueSize to 1 and disabling Aero through RadeonPro as referred to in my previous post (see here (http://forum.arcadecontrols.com/index.php/topic,142143.msg1517953.html#msg1517953)).
It will be interesting to see whether it can improve the next frame response significantly above the 25%, for Windows 7 at least. Could you possibly perform the test with both regular GM and the new one?
If you have any questions or doubts about setting up RadeonPro correctly as described, then please let me know.
-
Hopefully you have some time left to do a test while forcing the FlipQueueSize to 1 and disabling Aero through RadeonPro as referred to in my previous post (see here (http://forum.arcadecontrols.com/index.php/topic,142143.msg1517953.html#msg1517953)).
It will be interesting to see whether it can improve the next frame response significantly above the 25%, for Windows 7 at least. Could you possibly perform the test with both regular GM and the new one?
If you have any questions or doubts about setting up RadeonPro correctly as described, then please let me know.
My understanding is that as long as you're getting next frame response, even if it's 25% or 90% of the times, there can't be a frame queue. Which I consider that has been demonstrated for the ddraw case.
The RadeonPro tool FlipQueueSize must be the same as the SetMaximumFrameLatency method but operating externally, in the same way that you can override the vsync settings of any app. I'd be surprised if it did something different (I'd be forced to reverse-engineer it), obviously it's worth a try.
I'm afraid the problem is that even when the queue is set to its minimum (1), d3d/ati insists on scheduling the flip instead of performing it immediately during next retrace. I've tried to compesate for this by inserting an additional vertical retrace sync after the present call (in case this was the problem). Ideally this would need to be done only after the first present call, assuming there's only one frame mismatch.
Modern video APIs suck big time.
-
https://msdn.microsoft.com/en-us/library/windows/apps/dn448914.aspx (https://msdn.microsoft.com/en-us/library/windows/apps/dn448914.aspx)
http://www.ogre3d.org/forums/viewtopic.php?f=5&t=50486&sid=a544d484cf878ca96310324443b2c862&start=25 (http://www.ogre3d.org/forums/viewtopic.php?f=5&t=50486&sid=a544d484cf878ca96310324443b2c862&start=25)
-
The RadeonPro tool FlipQueueSize must be the same as the SetMaximumFrameLatency method but operating externally, in the same way that you can override the vsync settings of any app. I'd be surprised if it did something different (I'd be forced to reverse-engineer it), obviously it's worth a try.
In theory they would be the same yes. But I've learned to distrust the theory with regards to PC's and Windows.
Why I think this could be different is that
- calling SetMaximumFrameLatency() will only really do something if it's correctly implemented in the video driver, which is an unknown. Especially since it's ATI. Remember your finding on hardcoded flipqueuesize in the ATI drivers for XP?
- setting the FlipQueueSize is an undocumented feature of -earlier- ATI drivers, such as the one CRT Emudriver is based upon (catalyst 13.1 for Win 7).
Note that in one thread at the radeonpro board someone had asked ati for what the different flipqueuesize values meant and he got answered "I got in touch with AMD and they refuse to answer me because changing the queue size is not supported officially by AMD".
So it's just healthy scepticism which makes me think that we shouldn't rule out some wonky stuff with the video driver. Using the undocumented feature** to force the driver to using a FlipQueueSize of 1 seems like a sensible test to do.
**From reading comments of the programmer of RadeonPro, the -early- Catalyst drivers look for a registry key that may override the default FlipQueueSize value. It's actually this undocumented feature that RadeonPro uses to change the FlipQueueSize.
Hopefully vicosku's tests will provide us with the necessary evidence on its effectiveness.
An additional thought:
Apparently during 2013 this undocumented feature was removed from the ATI driver. So for Catalyst 13.1 (our current one) the RadeonPro tool works, but for Catalyst 13.9, the last driver released for HD4XXX cards, the feature apparently will not work anymore.
This sparks another thought, maybe in Catalyst 13.9 (released at the end of 2013) they not only disabled the undocumented registry key feature for the FlipQueueSize, but may actually have changed/improved the way it works for Windows 7? Possibly (small chance) the call to SetMaximumFrameLatency will do things differenty in this driver?
-
I have a theory of what could be happening with D3D9ex, it'd be good to confirm that D3D9ex *without* the fd_mod diff actually lags a frame more (in other words, that the fd_mod actually does something).
I compiled with your d3d9ex_koopah.diff (No fd_mod) and ran a test with -video d3d -frame_delay 9. 18/20 inputs registered on next-frame! I wonder if I somehow did something wrong...the two source files show the d3d9ex modiciations though, so I figure it must be correct. I also removed the mame.ini I used in my previous tests in order to rely on switches entirely. I thought this change might be somewhat responsible, but running the fd_mod version you posted in the same way gave the same 2nd frame results I posted earlier, so I don't think my mame.ini affected the results at all. Here's the video.
d3d9ex_only (https://mega.co.nz/#!3QthWJQT!7ufJSByNoJ7gb5TZvn9zN4gPUOppxcNDAFEuKPEtVu4)
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?
RadeonPro (https://mega.co.nz/#!TN1TRYzR!O6oLcTT6NCHs-3HoY4Gh8TXSNJDb9uUhe-eWcIjITN4)
I need to test these variables some more with the asio patch. I've only done a little and need to quit for the day, but initial results are still requiring that I increase audio latency greatly when using high frame_delay values with either solution above depending on the game, of course. For example, I have to pull all the way back to Frame_delay 1 to stop severe audio issues with sf2 at lower ASIO latencies with ddraw, and I don't get next frame response with this low of an FD setting. I'm also getting similar buffer overrun/underrun results from the d3d9ex version as I do with the official version, so I'm still a little suspicious of the build I compiled. I'll let you know how it goes.
-
The RadeonPro method is definitely worth a try. Just a bit too pessimistic due to the 9ex fiasco.
Just made another attempt, this time flushing the command queue after presenting, as the second link I posted above suggests. Here's the binary:
https://www.dropbox.com/s/qp1b0t4v8sbcl8i/mame64_d3d9ex_flush.7z?dl=0 (https://www.dropbox.com/s/qp1b0t4v8sbcl8i/mame64_d3d9ex_flush.7z?dl=0)
(the patch is to be applied right after koopah's one, the old "fd_mod" is no longer necessary)
-
Vicosku, I'm afraid if you only applied koopah's patch then old frame delay code is still present, which has the hack that allows next frame response but causes unstable timing. The "fd_mod" patch removed that hack.
-
Thanks for the new version! I'll try it out tomorrow.
And thanks for the explanation. I guess I misunderstood your comment about confirming if d3d9ex without fd_mod lags more. Let me know if there's something else you'd like me to try.
-
I guess I misunderstood your comment about confirming if d3d9ex without fd_mod lags more.
I'm sorry I made you waste your time, my fault. I meant without fd_mod but also without the hack that GM applies (the code snippet just above the present call). Anyway you'd need a custom build for that. Nevermind.
-
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 (http://forum.arcadecontrols.com/index.php/topic,142143.msg1516929.html#msg1516929) 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.
-
I wanted to mention something on the ASIO topic. Previously I've mentioned (http://forum.arcadecontrols.com/index.php/topic,142143.msg1516929.html#msg1516929) 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 (http://forum.arcadecontrols.com/index.php?topic=141869.0) .
This from the first post: 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 (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.
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
-
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.
-
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! :) )
-
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)
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 (http://forum.arcadecontrols.com/index.php/topic,142143.msg1484914.html#msg1484914)
-
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.
-
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.
-
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!
-
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
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
-
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).
-
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
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).
-
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.
-
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.
-
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.
-
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.
-
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?
-
I've been testing a new mod. This is for plain D3D9. In drawd3d.c, just replace this function:
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:
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!
-
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?
-
The value m_height here:
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.
-
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,
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
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.
-
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.
-
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.
-
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.
-
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.
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
m_speed(original_speed_setting())
-
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.
-
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.
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 :)
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 (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...
-
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%.
-
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.
-
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:
-
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. :)
-
Great news guys, it's awesome that gm is getting so close to realtime performance.
Looking forward to testing the next release!
-
Looking forward to testing the next release!
Same here! Exciting stuff!
-
Using that information, maybe, it should be possible to deduce the proper max value for frame_delay, automatically.
:cheers: :applaud: :burgerking:
-
Indeed, very exciting news here. Great hope to see a concept/proof in next release ;-)
-
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.
-
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.
When combining two experimental features, weird and exotic problems are bound to arise.
Quite true.
-
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) ;-)
-
Intealls,
Until the next release is out, could you possibly test the game Mega Turrican (https://en.wikipedia.org/wiki/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?
-
Intealls,
Until the next release is out, could you possibly test the game Mega Turrican (https://en.wikipedia.org/wiki/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.
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.
-
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.
-
When adding Framedelay 8, we're "postponing" the sample generation and copy to audio buffer by almost a full frame.
at earliest audio can begin playing at the end of the first frame.
Not really.
Ideally, an emulator running on a reasonably powerful cpu is most of its time waiting for vsync, because the time it takes to actually emulate a frame is close to zero. What we do with frame delay is to wait until the very last moment to emulate the frame so we can read the must up-to-date input. Perfection would be to be able to emulate the whole frame during the vertical retrace period, although we're not there yet. We need to start the emulation a bit before vertical retrace (frame_delay 8) so we don't miss the retrace. So actually "first frame" starts after having waited already (fd 8) and the frame contents (audio and video) are presented almost immediately after the actual emulation.
-
When adding Framedelay 8, we're "postponing" the sample generation and copy to audio buffer by almost a full frame.
at earliest audio can begin playing at the end of the first frame.
Not really.
Ideally, an emulator running on a reasonably powerful cpu is most of its time waiting for vsync, because the time it takes to actually emulate a frame is close to zero. What we do with frame delay is to wait until the very last moment to emulate the frame so we can read the must up-to-date input. Perfection would be to be able to emulate the whole frame during the vertical retrace period, although we're not there yet. We need to start the emulation a bit before vertical retrace (frame_delay 8) so we don't miss the retrace. So actually "first frame" starts after having waited already (fd 8) and the frame contents (audio and video) are presented almost immediately after the actual emulation.
Thanks for clarifying this. My fd_theory picture proved to be correct. :)
-
Guys, thanks for thinking with me.
But I'm not sure if you're fully appreciating my point.
Of course for video you are right, but why would audio need to wait for vertical sync to start playing?
My comment was that it actually doesn't need to wait 16.7ms (60hz) for vsync, but can start as soon as audio data is ready.
For example Commodore Amiga is known to use different sync methods (besides vsync) for audio replay routines, such as cpu or other system timers (cia).
So why should audio need to wait until the end of raster to start playing? If I'm syncing to an internal clock, like is possible with Amiga, couldn't it be that audio starts playing much earlier than vblank, for example after the first few milliseconds (or whenever audio data is ready) into a frame?
Hope I'm making myself clearer now!
Edit: to clarify further, my hypothesis for above example would be:
- Real Commodore Amiga: generates samples at the beginning of the first frame, starts playing sound immediately, does not wait for vsync
VS
- MAME emulated Commodore Amiga: generates samples at end of frame (framedelay 8 ), waits for vsync, then starts playing audio
Conclusion: MAME emulated Commodore Amiga would lag almost a frame regarding when audio replay is started versus the real Amiga.
-
Of course for video you are right, but why would audio need to wait for vertical sync to start playing?
Audio doesn't wait, it starts playing immediately. It's the emulation of the audio hardware what waits.
-
Of course for video you are right, but why would audio need to wait for vertical sync to start playing?
Audio doesn't wait, it starts playing immediately. It's the emulation of the audio hardware what waits.
So I'm right into thinking that audio replay in the emulation may start almost a frame later than the real hardware?
Please see also my clarification in previous post.
Edit: Calamity, I'm talking about the very first frame, not just any frame. So that would be the blue period in intealls picture where a real machine (say Amiga) starts playing audio already. Someone explain to me whether that is possible or not for the very first frame of a program that is executed on a real Amiga.
Maybe I'm missing the point how this is executed on real Commodore Amiga hardware?
-
So I'm right into thinking that audio replay in the emulation may start almost a frame later than the real hardware?
No, that's wrong. That's what I tried to explain :)
The error is in how you're using the concept of "first frame". The "first frame" in the emulation starts *after* the first vertical retrace happens, not before. At that point, the frame that just got emulated an instant before vertical retrace is presented, and represents the point where the Amiga is turned on.
-
But my concept of the very first frame is intealls picture. The blue part is the part *before* vsync :)
Edit: forget for a second the whole emulation part. Emulation is out of the picture. We're only talking about real hardware now.
In intealls picture the very first frame (on top of his picture) is starting with the blue part. This is where stuff is already generated in the computer. Is it possible that real hardware starts playing audio there already?
-
Real hardware will start playing audio during the first frame.
But that first frame, in the emulation, corresponds with the second iteration of the loop (second column in intealls' drawing).
The first iteration of the loop is required to synchronize the emulator with the vertical retrace for the first time. Emulation has not started yet.
-
But my concept of the very first frame is intealls picture. The blue part is the part *before* vsync :)
Edit: forget for a second the whole emulation part. Emulation is out of the picture. We're only talking about real hardware now.
In intealls picture the very first frame (on top of his picture) is starting with the blue part. This is where stuff is already generated in the computer. Is it possible that real hardware starts playing audio there already?
The very first frame is emulated just like any other frame. Think of the emulation as a slight delay.
-
Hi guys, thanks for your thoughts on this, I understand what you're saying on real hardware versus emulation.
It doesn't close the topic for me yet though. There's still itching something about there being added audio latency between fd 0 and fd 8 in emulation context. Please see attached picture, outlining why in my view framedelay adds to audio latency.**
First let's see if we agree on this case. If we do, it may give an interesting new insight (at least for me) on the case of real hardware vs emulation fd 8 vs emulation fd 0.
**Note that this considers the case from an optimal emulator standpoint, MAME may or may not (yet) work this way, I don't know. I guess you are able to tell.
-
Your drawing is correct. Your conclusion is not.
With fd 8, the actual concept of emulation starts at instant t-1, not t-0, that's the point. It starts with video and audio perfectly synchronized. The first interval (t0-t1) is not part of the emulation yet, it's just used to get synchronized with the retrace.
Your scenario with fd 0 shows the typical case in emulation. It doesn't inply lower audio latency but higher video latency (audio/video mismatch in any case).
-
This is puzzling. How can the picture be correct but the conclusion not?
In both cases you -need- to synchronize with the PC retrace before you can start to do anything. That's the first blue dot in the picture. I don't see how you magically shift the emulation with framedelay 8 before that blue dot, but with framedelay 0 you do not? The starting point for both approaches must be the same, and that is the blue dot in the picture. This is the really puzzling part. You keep insisting that fd 8 somehow is started before that vsync, but I really don't understand why it then can be the same for fd0? It seems like you're creating an apple and a pear from two apples.
Could you possibly enlighten your thinking a bit with some illustration?
-
You keep insisting that fd 8 somehow is started before that vsync
No, I'm not saying that at all.
Dr., I'm already doing my best to try to explain this, not sure if I can reformulate my explanation any better.
My point is that in your drawing, in the fd 8 part, you have to put the origin of your reference system at t-1. The part on the left of t-1 doesn't belong to emulation, although we need it for implementation reasons. So for the latency discussion you should cover the part on the left with a piece of paper. It's meaningless to measure latency assuming t-0 as the origin of time, that's the point.
-
Calamity, I know you're trying your best to explain, and I'm sure we will get on the same page.
I've created a new picture to try and shed more light on the matter (at least for myself), this time incorporating real hardware.
Please note that in the picture all three approaches, real Amiga, emu fd8 and emu fd0, are aligned to when the first scanline of the video display is starting (marked by the yellow boxes). This point in time is called "t0".
Note that there are now only "t-1" (t minus 1), "t0" and "t1".
On the right, there is a comparison between each approaches' first frame. based on this I'm still holding the thought that it's only possible with framedelay 0, to match the "front running" of audio of the real Amiga, versus t0, the moment video display is started in all three approaches and how audio latency will be perceived.
See it as that we are physically aligning the video display of all three aproaches at moment t0, for recording purposes. That we take as starting point for drawing how frames are prepared in all three and at what point in time audio is started in all three approaches.
Hope I'm not asking too much, but it will be of great help: Could you please load up attached picture in paint or something and scratch what needs to be changed to get clarity on all three approaches? Since a picture tells a thousand words, I think we'll quickly get on the same page again and save more discussion ;).
It would be great if we could work towards a final version of this picture, such that we can keep it for future reference.
-
Hopefully this clarifies my point.
-
Thanks Calamity for adding your changes. To be fair, I'm not sure if it helps clarify your point.
The problem (in my personal view) remains that you shift the very first frame emulation in fd0 (the yellow dot) by one vsync to the right. You're effectively starting the fd0 emulation one whole vsync later than the fd8 case, only then to come to the (obvious) conclusion that the fd0 case has one frame of lagging video (and audio). That doesn't seem like the right logic to me.
It must be possible for you to keep the video display start for all three at the reference "t0" and still explain your view?
I have uploaded the spreadsheet on which the picture is based to google sheets. It can be accessed here: https://docs.google.com/spreadsheets/d/1839b76DcZa9G90xmN5TUHLtrDwOhtEoBzxZzcv3euPc/pubhtml (https://docs.google.com/spreadsheets/d/1839b76DcZa9G90xmN5TUHLtrDwOhtEoBzxZzcv3euPc/pubhtml). Maybe helpful (for anyone) to shed new light on this matter.
-
You're effectively starting the fd0 emulation one whole vsync later than the fd8 case
Not really.
If you see the drawing, the yellow square (the emulation) in fd 0 is just two squares to the right with respect to fd 8. Not a whole frame period. For the purpose of this explanation, you could assume the blue vsync square to have zero size, so the yellow squares would be shifted by one position only, with the black thick line representing the retrace in the middle. That's where they must be aligned for a proper comparison.
You are mistaking the start of emulation with the start of the emulator program.
only then to come to the (obvious) conclusion that the fd0 case has one frame of lagging video (and audio)
This is not the conclusion, it's the premise!! :D
It is a fact! The reason why we implemented frame delay in the first place. And you were there! :D
It must be possible for you to keep the video display start for all three at the reference "t0" and still explain your view?
Of course you can do that but it's fooling yourself. What you want to align is not the video display start, but the game logic (real and emulated). That's what I did in my modified drawing.
-
Hey guys,
how about this one.
Let's assume for a second that we're emulating a system with _no_ input delay, and _no_ audio output delay. I think the closest actual thing in real-life would be a completely analog machine. The video still needs to be synchronized against the vertical refresh, but the audio system could theoretically be completely decoupled.
If we only poll for input changes once per video frame, we have a problem, since the system we try to emulate instantaneously responds to input, regardless of when it happens.
To emulate the system perfectly, we would have to poll the input at an infinite speed. I highly doubt that the majority of systems MAME emulates do anything remotely related to this, so the point is probably mute, and I'm certainly no expert on these matters.
-
If we only poll for input changes once per video frame, we have a problem, since the system we try to emulate instantaneously responds to input, regardless of when it happens.
We hold this debate long ago and concluded that this type of emulation ("frame-based" emulation) can only be "perfect" for games that poll input once per frame. If we could actually do scanline-based emulation (hsynced instead of vsynced) it should be possible to get closer to that. But that would probably mean rewriting all emulators, and serious implementation issues with video APIs that expect you to work with frames rather than scanlines.
-
You're effectively starting the fd0 emulation one whole vsync later than the fd8 case
Not really.
But you are. From what I understand from your reasoning, the frame emulation in the case of fd0 falls *after* the vertical sync that you allow the fd8 case to catch. There's no grey area. Because of this the fd0 case has to wait for the next retrace to start displaying. There's your one frame of delay.
If you see the drawing, the yellow square (the emulation) in fd 0 is just two squares to the right with respect to fd 8. Not a whole frame period. For the purpose of this explanation, you could assume the blue vsync square to have zero size, so the yellow squares would be shifted by one position only, with the black thick line representing the retrace in the middle. That's where they must be aligned for a proper comparison.
Does the frame emulation in the fd0 case (the yellow square) fall *before* or *after* the vertical sync that you allow the fd 8 case to catch? It's either a before or after, no inbetween ;)
You are mistaking the start of emulation with the start of the emulator program.
What makes you think that I'm mistaking the two? How would that impact the analysis?
only then to come to the (obvious) conclusion that the fd0 case has one frame of lagging video (and audio)
This is not the conclusion, it's the premise!! :D
It is a fact! The reason why we implemented frame delay in the first place. And you were there! :D
Of course I was there, we were partying like it was 1999 :)
But... The fact that we came up with the whole framedelay concept was to get frame emulation as close as possible to the video display (vsync), to minimize input latency to almost the real hardware levels. This has little to do with case about audio latency I'm arguing here.
You may be mixing up / mingling two different cases:
- Input latency versus video display
- Audio latency versus video display.
They are two very different cases in emulator context. (Where you have to compensate for all kind of related buffer lags of the host system versus real hardware).
Of course I'd like someone else to prove me wrong, very much so, but unfortunately, I haven't seen any diagram or solid arguments that depicts that it's working differently than what I'm currently assuming and showing.
P.S. @ Intealls, sorry that we're highjacking your thread with this stuff! We'll get back to ASIO testing as soon as the next release is here, this is just inbetween chatter! :D
-
If we only poll for input changes once per video frame, we have a problem, since the system we try to emulate instantaneously responds to input, regardless of when it happens.
We hold this debate long ago and concluded that this type of emulation ("frame-based" emulation) can only be "perfect" for games that poll input once per frame. If we could actually do scanline-based emulation (hsynced instead of vsynced) it should be possible to get closer to that. But that would probably mean rewriting all emulators, and serious implementation issues with video APIs that expect you to work with frames rather than scanlines.
Great, I *think* that was what Dr. Venom was reaching for?
-
The important conclusion I'm starting to draw is that with Framedelay at say 8 we are able to mimimize input latency versus real hardware, but it comes at a cost. The cost is that Audio latency is increasing by the amount that input latency is decreasing.
That's is utterly wrong, my friend.
Of course I'd like someone else to prove me wrong, very much so, but unfortunately, I haven't seen any diagram or solid arguments that depicts that it's working differently than what I'm currently assuming and showing.
With the material in this thread you should already accept my argument as proved. If you can't see it crystal clear, it's probably my fault and the limitations of my English. I think I give up now.
-
- Does the frame emulation in the fd0 case (the yellow square) fall before or after the vertical sync signal that you allow the fd 8 case to catch?
- What makes you think that I'm mistaking the start of emulation with the start of the emulator program?
-
(Sorry I edited your post by accident when trying to answer, maybe you could restore it to its previous state :( )
No worries Dr.
- Does the frame emulation in the fd0 case (the yellow square) fall before or after the vertical sync signal that you allow the fd 8 case to catch?
It falls after the vertical retrace, obviously. But that's let's say 1 ms after the fd 8 case, not the whole 16.7 ms as you're implying. The fact that in practice it makes the video start 16.7 ms later is exactly the problem we're trying to fight with frame delay, in other words, the misalignment of game logic and video output.
But what matters is that the game logic is aligned in both cases around t0 (well *nearly*). The game logic includes polling input and filling audio buffers.
- What makes you think that I'm mistaking the start of emulation with the start of the emulator program?
Because you're maintaing the fallacy (IMHO) that just because in the fd 0 case the first audio samples arrive to the speakers before they do in the fd 8 case, this means the audio latency is lower.
The reason why this is a fallacy is that latency only has a meaning when it is relative to the game logic (including input).
-
Regarding all this discussion about frame delay.
Currently, the flip queue is bypassed when using frame_delay with CRT Emudriver.
I was thinking, couldn't D3D9Ex (with the flip queue set to 1) be used, along with the frame_delay code, to provide next frame response with D3D to virtually any driver? This is all theoretical of course, I know nothing about the innards of a video driver. :)
-
I was thinking, couldn't D3D9Ex (with the flip queue set to 1) be used, along with the frame_delay code, to provide next frame response with D3D to virtually any driver?
This should be currently possible with D3D9 too, although it's never been tested. The limitation is the time it takes the gpu to render the frame. While this is close to zero when using low resolutions (not necessarily CRT Emudriver), it becomes macroscopic when stretching over high resolutions is involved (typical case with nowadays monitors).
-
I was thinking, couldn't D3D9Ex (with the flip queue set to 1) be used, along with the frame_delay code, to provide next frame response with D3D to virtually any driver?
This should be currently possible with D3D9 too, although it's never been tested. The limitation is the time it takes the gpu to render the frame. While this is close to zero when using low resolutions (not necessarily CRT Emudriver), it becomes macroscopic when stretching over high resolutions is involved (typical case with nowadays monitors).
Thanks for the info!
Anyway, getting back to the topic at hand, here's 0.163 + ASIO, it contains a whole lot of changes and should work better in almost every regard.
0.163 r1.5 (https://mega.nz/#!n5QWWRJJ!_j4YbMzoIh79iUJ-asTdPeByE0YNz9CK0kEhwQ_jJe4)
Edit: r1 fixes an issue with fastforwarding.
Edit: r1.5 contains a new batool version, with a drastically improved frequency calibration routine
IMPORTANT: -speed needs to bet set to 0.0, either start from a fresh ini or edit your existing one.
The pitch shifts (most of them) have been replaced with faint (most of the time) crackling, which is undoubtedly the lesser of two evils.
The sync disparity issue is gone.
Performance with frame_delay should be a lot better. Many thanks Calamity for helping me debug this!
I actually can't think of a single thing that ought to be worse compared to previous builds, aside from the fact that underruns might be more frequent, although they should be much harder to actually hear.
And also, a big thanks to everyone posting in this thread for their testing and feedback, and as always, please report any issues you might encounter.
0.163 is built with MinGW (without D3D9Ex patch), since changes done to this MAME version seem to break MSVC (2013) builds.
I've also decided to post an alternative 0.162 MSVC build with the D3D9Ex patch, since I've performed fairly extensive testing against this one.
http://www.mediafire.com/download/rl8hemtc4fwl2hr/gmame162-asio-msvc-d3d9ex.zip (http://www.mediafire.com/download/rl8hemtc4fwl2hr/gmame162-asio-msvc-d3d9ex.zip)
Also, don't stare yourselves blind on the over-/underrun counter, I'll most likely change its behavior come next release.
Edit: Noticed minor error in patch, fixed in r1
-
(Sorry I edited your post by accident when trying to answer, maybe you could restore it to its previous state :( )
No probs. It's shorter now, so I guess that's better :)
Because you're maintaing the fallacy (IMHO) that just because in the fd 0 case the first audio samples arrive to the speakers before they do in the fd 8 case, this means the audio latency is lower.
The reason why this is a fallacy is that latency only has a meaning when it is relative to the game logic (including input).
Thanks for all your answers in this discussion on framedelay and audio latency. I know I can be a little stubborn sometimes! I finally see your point of view and how perceived lower latency may fit the fd0 case (it's actually not really lower latency, as you said, that's why I put it in italics).
I made a new picture based on the one that you adjusted, with a few comments on the three approaches besides it. See the attachment. It was useful for me to reiterate and get my head around it!
Please let me know in case you have any suggestions for additional finetuning.
Anyway, getting back to the topic at hand, here's 0.163 + ASIO, it contains a whole lot of changes and should work better in almost every regard.
http://www.mediafire.com/download/wgoopf9d6ohka9e/gmame163-asio.zip (http://www.mediafire.com/download/wgoopf9d6ohka9e/gmame163-asio.zip)
The pitch shifts have been replaced with faint (most of the time) crackling, which is undoubtedly the lesser of two evils.
The sync disparity issue is gone.
Performance with frame_delay should be a lot better. Many thanks Calamity for helping me debug this!
I actually can't think of a single thing that ought to be worse compared to previous builds, aside from the fact that underruns might be more frequent, although they should be much harder to actually hear.
And also, a big thanks to everyone posting in this thread for their testing and feedback, and as always, please report any issues you might encounter.
0.163 is built with MinGW (without D3D9Ex patch), since changes done to this MAME version seem to break MSVC (2013) builds.
I've also decided to post an alternative 0.162 MSVC build with the D3D9Ex patch, since I've performed fairly extensive testing against this one.
http://www.mediafire.com/download/rl8hemtc4fwl2hr/gmame162-asio-msvc-d3d9ex.zip (http://www.mediafire.com/download/rl8hemtc4fwl2hr/gmame162-asio-msvc-d3d9ex.zip)
Many thanks intealls! Will be testing it soon and provide some feedback. Great stuff! :)
Also, don't stare yourselves blind on the over-/underrun counter, I'll most likely change its behavior come next release.
Could you possibly tell us a little bit more about that? May we still use it to benchmark with this release?
Edit: changed the picture slightly. fd 0 case is now called "least accurate", that's better than "inaccurate".
-
Many thanks intealls! Will be testing it soon and provide some feedback. Great stuff! :)
No problem. You should thank Calamity for helping out with the frame delay issue. That would have taken me a while to find. :)
Also, don't stare yourselves blind on the over-/underrun counter, I'll most likely change its behavior come next release.
Could you possibly tell us a little bit more about that? May we still use it to benchmark with this release?
Hmm, to change its behavior isn't really correct.
Currently, the strategy employed to handle overruns unfortunately tends to create a few underruns. I'm going to be quite busy the next few days, so rather than delaying the release and fixing this, I figured it's better to get it out, since it works so much better than the previous one.
However, it's much better if you guys would post the log created with -asio_log, since that makes it so much easier for me to understand what's going on, than simply the over-/underrun count, especially with this release.
-
Hi intealls,
Is it correct that the l.m script you posted earlier doesn't work with this release? I only get one garbled graph when running it in Octave.
-
Hi intealls,
Is it correct that the l.m script you posted earlier doesn't work with this release? I only get one garbled graph when running it in Octave.
That's correct, here's an updated version!
-
Thanks a lot, Intealls. I tested the .163 version briefly and agree that the crackling is much better than the pitch shifting. I barely notice it. Results with Frame_Delay also seem much better. Tron was a game that required large buffers no matter what I tried before, but now it doesn't have obvious problems at the lowest settings and frame_delay 8. Very nice. Sorry I don't have any scientific results for now, I just wanted to voice my appreciation to you and Calamity for these improvements.
-
Thanks a lot, Intealls. I tested the .163 version briefly and agree that the crackling is much better than the pitch shifting. I barely notice it. Results with Frame_Delay also seem much better. Tron was a game that required large buffers no matter what I tried before, but now it doesn't have obvious problems at the lowest settings and frame_delay 8. Very nice. Sorry I don't have any scientific results for now, I just wanted to voice my appreciation to you and Calamity for these improvements.
No problem!
I'd say currently (given a correct calibration frequency), it's good enough to use as a 'daily driver', so to speak. Games with varying speeds like sfiii should also sound a lot better. They'll sound even better once I get around to properly fixing the over->underrun issue.
I've also done a lot of testing with the Xonar DGX, but I've noticed that the output sometimes crackle, it's especially noticeable in Deathsmiles. Aside from that, I'd say the driver appears tighter than kX.
-
That's correct, here's an updated version!
From preliminary (though extensive) testing I have some first findings. My testing has fully concentrated on the genesis driver using a superresolution (-resolution 1280x0) with the game Mega Turrican. This means that GM is actually scaling the internal genesis video by either a factor 4 (genesis 320 wide) or 5 (genesis 256 wide) during each "screenswitch".
The first finding was that the internal scaling on "screenswitches" in the game (as described in an earlier post) would negatively impact the audio stability. The testcase was to wait on the title screen for the demo mode to begin, then press fire (to go back to the title screen). Rinse and repeat. On most of the "screenswitches" an underrun would occur very shortly after the switch. After enough rinse and repeating I realized that I still had my HD 4830 in my machine from some testing a while ago. Thinking the internal video scaling could be involved, I changed the 4830 to my HD 4850. And indeed the previous underruns at the screenswitches were completely gone when using the same audio latency test settings. This implies that a fast(er) video card actually matters for sound/ASIO stability, when the driver switches screens and you're using a super resolution.
Next finding has more to do with the ASIO release itself. I found through using the Octave graphs that, on each time after starting the emulator, at the beginning there is some quite significant instability in the number of samples in the audio buffers before stabilizing. This was repeatable over and over regardless of other settings. I finally gathered this had to do with the screenswitch that is done on emulator startup from the PC desktop resolution to the game resolution. I found a way of proving this, as you can enable "show game info" (skip_gameinfo 0) in the mame.ini, which together with "disable_nagscreen_patch 1" will physically switch the screen resolution from the desktop resolution to the groovymame resolution (1280x224) *before* starting the game/driver, to show some game information. This means that there's no screenswitching involved anymore at the moment the driver is started. And indeed, following this procedure the large instability in samples in the buffer at startup of the game / driver is gone. This can be repeated over and over.
I've attached two pictures, the one is of startup with screenswitching already done before driver start (skip_gameinfo 0) and the other with screenswitching at startup of the driver (skip_gameinfo 1). You'll see that the first method has a much more stable profile at start (look at the Y scale values at start) than the second. This is the same for both using d3d and ddraw.
This seems to imply, that after a physical screen switch, the screen refresh rate may not be stable for a short time period. If that would be the case (maybe you can verify with your oscilloscope?), you could of course consider implementing a short delay after a physical screenswitch before you enable the audio video synchronization algorithm. My hypothesis is that this would allow for the screen refresh to stabilize, and not actually perform "synchronization" on wrong values. But I may be wrong of course, possibly something completely different is causing this behaviour. Lastly, do note that I have attached both a CRT screen and an LCD to my PC, so maybe that impacts screen switching speed of the CRT.
A third finding was that using "multithreading 1" actually seems to generate less stable audio than having it off. It could especially be seen in the recorded speed against audio update. With multithreading off it would be a flat line, and with it on it would show minor variations in the line.
The fourth finding is that for the genesis driver at least, in combination with my system configuration, I need a marginally larger asio_holdoff (while using a calibrated callback frequency) than the default 864 to get really nice stable results at low driver latency. But once all this finetuning is done, the audio for this driver is running really stable!
P.S. I left testing of high framedelay values out of the equation for now (everything tested with fd 2), as I first want(ed) to get stable results before step by step increasing the fd value and see how that will impact the results. Before testing this, I may wait for your next release first.
-
That's correct, here's an updated version!
From preliminary (though extensive) testing I have some first findings. My testing has fully concentrated on the genesis driver using a superresolution (-resolution 1280x0) with the game Mega Turrican. This means that GM is actually scaling the internal genesis video by either a factor 4 (genesis 320 wide) or 5 (genesis 256 wide) during each "screenswitch".
The first finding was that the internal scaling on "screenswitches" in the game (as described in an earlier post) would negatively impact the audio stability. The testcase was to wait on the title screen for the demo mode to begin, then press fire (to go back to the title screen). Rinse and repeat. On most of the "screenswitches" an underrun would occur very shortly after the switch. After enough rinse and repeating I realized that I still had my HD 4830 in my machine from some testing a while ago. Thinking the internal video scaling could be involved, I changed the 4830 to my HD 4850. And indeed the previous underruns at the screenswitches were completely gone when using the same audio latency test settings. This implies that a fast(er) video card actually matters for sound/ASIO stability, when the driver switches screens and you're using a super resolution.
Nice find!
Next finding has more to do with the ASIO release itself. I found through using the Octave graphs that, on each time after starting the emulator, at the beginning there is some quite significant instability in the number of samples in the audio buffers before stabilizing. This was repeatable over and over regardless of other settings. I finally gathered this had to do with the screenswitch that is done on emulator startup from the PC desktop resolution to the game resolution. I found a way of proving this, as you can enable "show game info" (skip_gameinfo 0) in the mame.ini, which together with "disable_nagscreen_patch 1" will physically switch the screen resolution from the desktop resolution to the groovymame resolution (1280x224) *before* starting the game/driver, to show some game information. This means that there's no screenswitching involved anymore at the moment the driver is started. And indeed, following this procedure the large instability in samples in the buffer at startup of the game / driver is gone. This can be repeated over and over.
I've attached two pictures, the one is of startup with screenswitching already done before driver start (skip_gameinfo 0) and the other with screenswitching at startup of the driver (skip_gameinfo 1). You'll see that the first method has a much more stable profile at start (look at the Y scale values at start) than the second. This is the same for both using d3d and ddraw.
This seems to imply, that after a physical screen switch, the screen refresh rate may not be stable for a short time period. If that would be the case (maybe you can verify with your oscilloscope?), you could of course consider implementing a short delay after a physical screenswitch before you enable the audio video synchronization algorithm. My hypothesis is that this would allow for the screen refresh to stabilize, and not actually perform "synchronization" on wrong values. But I may be wrong of course, possibly something completely different is causing this behaviour. Lastly, do note that I have attached both a CRT screen and an LCD to my PC, so maybe that impacts screen switching speed of the CRT.
The refresh rate is going to be stable, however, the game speed at start up is not. I think MAME needs some time to get in tune, this is kept 'in check' by setting -noskip_gameinfo and -disable_nagscreen_patch, since the emulator will pause at startup, letting everything initialize in the background. If aiming for as perfect emulation as possible, one should definitely consider setting these. Great observation!
A third finding was that using "multithreading 1" actually seems to generate less stable audio than having it off. It could especially be seen in the recorded speed against audio update. With multithreading off it would be a flat line, and with it on it would show minor variations in the line.
The fourth finding is that for the genesis driver at least, in combination with my system configuration, I need a marginally larger asio_holdoff (while using a calibrated callback frequency) than the default 864 to get really nice stable results at low driver latency. But once all this finetuning is done, the audio for this driver is running really stable!
Good to hear it. :) Many thanks for pointing this out. I think the holdoff should be changed so that it can be evenly divided with the ASIO latency. I see you're using a buffer size of 128 samples, with the default holdoff of 864, that gives 864/128 = 6,75, which is suboptimal, since BASSASIO will most likely (not guaranteed) be fetching latency-sized chunks. If increased to 896, BASSASIO could do about 7 fetches without getting new sample additions from GM.
I'm going to have to look into multithreading behavior.
P.S. I left testing of high framedelay values out of the equation for now (everything tested with fd 2), as I first want(ed) to get stable results before step by step increasing the fd value and see how that will impact the results. Before testing this, I may wait for your next release first.
Great! Thanks a lot for these thorough tests. I'm currently trying to figure out a way to get the calibration time down, and when that's done, I'm going to try and sort out the buffer issues shown in the bottom graph of your post.
Edit: Also, as Calamity has pointed out, ddraw will not be available in future Windows versions, so all my current and future testing has been and will be performed against D3D.
-
The refresh rate is going to be stable, however, the game speed at start up is not. I think MAME needs some time to get in tune, this is kept 'in check' by setting -noskip_gameinfo and -disable_nagscreen_patch, since the emulator will pause at startup, letting everything initialize in the background. If aiming for as perfect emulation as possible, one should definitely consider setting these. Great observation!
Thanks, good to know how this works.
A third finding was that using "multithreading 1" actually seems to generate less stable audio than having it off. It could especially be seen in the recorded speed against audio update. With multithreading off it would be a flat line, and with it on it would show minor variations in the line.
The fourth finding is that for the genesis driver at least, in combination with my system configuration, I need a marginally larger asio_holdoff (while using a calibrated callback frequency) than the default 864 to get really nice stable results at low driver latency. But once all this finetuning is done, the audio for this driver is running really stable!
Good to hear it. :) Many thanks for pointing this out. I think the holdoff should be changed so that it can be evenly divided with the ASIO latency. I see you're using a buffer size of 128 samples, with the default holdoff of 864, that gives 864/128 = 6,75, which is suboptimal, since BASSASIO will most likely (not guaranteed) be fetching latency-sized chunks. If increased to 896, BASSASIO could do about 7 fetches without getting new sample additions from GM.
Great, this does indeed make a noticable difference. It got me into further testing, and I was finally able to get to a fully stable (zero over-/underruns, and stable Octave graphical profile), at a whoppingly low latency of 48 with a holdoff of 576! We're talking 13ms of total audio latency here. That's really great! See attached genesis-ddraw-bufsize48-holdoff576-fd2_showgameinfoscreen.png for the profile.
I've been testing both ddraw and d3d, but unfortunately d3d doesn't match the performance of ddraw. When running these low latency settings with d3d it will continuously underrun and/or crash the emulator. The lowest settings I got d3d to run without over- or underruns was with latency 48 and a holdoff of 864. But even then the profile doesn't look nowhere near as stable as the (lower latency) ddraw one. Just compare the previous one with genesis-d3d-bufsize48-holdoff864-fd2_showgameinfoscreen.png.
I also did some tests raising the framedelay value. After many tests, the conclusion is is that the higher the framedelay, the higher the audio latency needs to be to run the emulation without issues. In latency terms it's pretty much an inverse relationship, where unfortunately it seems that the audio latency needs to grow at a larger factor to accomodate for every additional unit (ms) in framedelay to keep the audio profile (perfectly) smooth.
At low latency (48/bufsize624) I can get to a framedelay of 4 while still keeping a very smooth profile, see genesis-ddraw-bufsize48-holdoff624-fd4_showgameinfoscreen.png. This again made me smile, I'm really happy with the result. Real hardware profile, here we come :)
After that I need to increase the audiobuffer by quite some margin to "fight" the spikes appearing in the audio profile. For example at a framedelay of 5 I already need to raise the holdoff to 960 and then it still isn't as stable as fd4 at the lower audio latency setting (compare genesis-ddraw-bufsize48-holdoff960-fd5_showgameinfoscreen.png). At fd 6, the audiobuffer needs raising to 1280, but even then allowing for some spikes. This is both the case for d3d and ddraw, where d3d is again less stable, compare:
genesis-ddraw-bufsize128-holdoff1280-fd6_showgameinfoscreen.png
genesis-d3d-bufsize128-holdoff1280-fd6_showgameinfoscreen.png
Note that I performed all tests both for d3d and ddraw, but for every single of these tests d3d will perform worse (I've compared over 20 settings). Given your and vicosku's earlier results I expect the relative performance of d3d and ddraw to vary between drivers, but for the genesis driver it's pretty clear.
Before I forget, what does the asio_playback_rate do in the settings? Could it somehow be used to further optimize settings?
Edit: Also, as Calamity has pointed out, ddraw will not be available in future Windows versions, so all my current and future testing has been and will be performed against D3D.
I understand the need to focus on d3d for a large part. The sad thing is that many of my tests show d3d to be inferior to ddraw.
As such I would like to raise a vote: Windows 7 is going to have extended support until 2020, so as long as ddraw is here (and as long as it's superior to d3d in certain aspects), please let us not forget about ddraw!
Apart from that, I'm -really- happy how the ASIO build is shaping up, great stuff, and great job from both you and Calamity! Thanks :)
-
Hi guys, sorry but I'm quite busy these days. Thanks a lot for the tests going on here. I'm happy to see a sort of agreement with Dr. Venom, finally.
Regarding the lower stability observed with -mt enabled, I think there's an explanation. In order to calculate current emulation speed, MAME measures the time elapsed once per frame. The exact point where this measurement is done is critical for the accuracy of the result. Usually, doing it right after we return from drawing is the best because the v-sync involved is more accurate than anything else. However, when running multithreaded, the draw operation is done in a separate blitting thread, while the main thread, where the speed measurement is to be performed, waits until it's signaled as ready by the blitting thread. This synchronization is done by means of an event object. The issue is, this mechanism requires the Windows scheduler to actually awake the main thread. This introduces an uncertainty relative to the time since we signal the event and the instant the thread is effectively awaken. This uncertainty doesn't happen when running single-threaded, as it will always take the same amount of cpu cycles to return from the drawing funtions back the main loop.
That said, the ultimate reason to use multithreading is to improve input response. So it should be determined if nowadays hardware still benefits from multithreading on this regard, as older hardware used to do. If this is still true, it might be possible to keep the multithreading just for input and force drawing and emulation in the same thread.
For the same reason, the advantage observed with ddraw seems to be directly related to the accuracy of the time it takes to ddraw to return. My understanding is this happens because ddraw involves no parallelization between cpu and gpu. That's what's behind the "superiority" of ddraw. If that is true, and we managed to completely break d3d parallelization, we'd achieve comparable results. The patch I posted some days ago had this purpuse, but it's poorly implemented. I'd like to do it *properly*. This means, it actually needs to grab data from the current modeline and make the timing dependent on absolute scanline numbers rather than uncertain "in-vblank" states. With that, it should really be very close to ddraw.
Although it's true W7 will be around for quite a long time, the fact is all the work I'm currently doing on the drivers is meant for relatively modern OS's and hardware (all my tests are for W8 now), and if it finally works some day, it'll be frustrating to have to stick to W7 just because of ddraw, so much work just to repeat the being-stuck-with-XP pattern, no please :)
It is also true that for the kind of synchronization we're seeking here, more powerful gpus might finally make some sense, as we'll need them to do all their scaling and stuff in the time of a few scanlines, in order to avoid static tearing.
-
That said, the ultimate reason to use multithreading is to improve input response. So it should be determined if nowadays hardware still benefits from multithreading on this regard, as older hardware used to do. If this is still true, it might be possible to keep the multithreading just for input and force drawing and emulation in the same thread.
Here's a video. (https://mega.co.nz/#!PBdhWCYT!wwnfmKYp_pNl7K9MzqsmOVGGlLC04cwf7Tq83oV2Dps) Looks like the input response is fairly on par with my multithreading videos. Here is the line I used and my first 20 counts. Intealls' recent .163 build was used.
mame64 sf2 -nomultithreading -frame_delay 8 -video d3d
Frame counts at 240FPS - 7,8,7,7,5,6,7,8,8,7,6,6,6,5,7,9,7,6,6,5
It is also true that for the kind of synchronization we're seeking here, more powerful gpus might finally make some sense, as we'll need them to do all their scaling and stuff in the time of a few scanlines, in order to avoid static tearing.
I'm using a 4550 on both of my machines right now. After Dr. venom's post, I ordered a 4890. I wanted it for some better performance in other games anyway, but it will be interesting to see if I experience any difference in GroovyMame.
Edit - I wanted to note that I am now using super resolutions, unlike in my previous tests.
-
Great, this does indeed make a noticable difference. It got me into further testing, and I was finally able to get to a fully stable (zero over-/underruns, and stable Octave graphical profile), at a whoppingly low latency of 48 with a holdoff of 576! We're talking 13ms of total audio latency here. That's really great! See attached genesis-ddraw-bufsize48-holdoff576-fd2_showgameinfoscreen.png for the profile.
That's quite amazing, with a latency that low, the Windows timer frequency starts to become a problem! Good to see the code holds up, at least in Genesis.
I've been testing both ddraw and d3d, but unfortunately d3d doesn't match the performance of ddraw. When running these low latency settings with d3d it will continuously underrun and/or crash the emulator. The lowest settings I got d3d to run without over- or underruns was with latency 48 and a holdoff of 864. But even then the profile doesn't look nowhere near as stable as the (lower latency) ddraw one. Just compare the previous one with genesis-d3d-bufsize48-holdoff864-fd2_showgameinfoscreen.png.
I also did some tests raising the framedelay value. After many tests, the conclusion is is that the higher the framedelay, the higher the audio latency needs to be to run the emulation without issues. In latency terms it's pretty much an inverse relationship, where unfortunately it seems that the audio latency needs to grow at a larger factor to accomodate for every additional unit (ms) in framedelay to keep the audio profile (perfectly) smooth.
At low latency (48/bufsize624) I can get to a framedelay of 4 while still keeping a very smooth profile, see genesis-ddraw-bufsize48-holdoff624-fd4_showgameinfoscreen.png. This again made me smile, I'm really happy with the result. Real hardware profile, here we come :)
Again, this is astonishing. What sound card/driver are you using? I don't think the cards I use with kX allow me to go to 48 without issues.
After that I need to increase the audiobuffer by quite some margin to "fight" the spikes appearing in the audio profile. For example at a framedelay of 5 I already need to raise the holdoff to 960 and then it still isn't as stable as fd4 at the lower audio latency setting (compare genesis-ddraw-bufsize48-holdoff960-fd5_showgameinfoscreen.png). At fd 6, the audiobuffer needs raising to 1280, but even then allowing for some spikes. This is both the case for d3d and ddraw, where d3d is again less stable, compare:
genesis-ddraw-bufsize128-holdoff1280-fd6_showgameinfoscreen.png
genesis-d3d-bufsize128-holdoff1280-fd6_showgameinfoscreen.png
Note that I performed all tests both for d3d and ddraw, but for every single of these tests d3d will perform worse (I've compared over 20 settings). Given your and vicosku's earlier results I expect the relative performance of d3d and ddraw to vary between drivers, but for the genesis driver it's pretty clear.
Thanks alot for these tests! I currently don't have access to a proper testing rig, so I can't test the D3D patch Calamity posted a while back (more below).
Before I forget, what does the asio_playback_rate do in the settings? Could it somehow be used to further optimize settings?
-asio_playback_rate can be used to force a resampling rate, using it will ignore the game speed so it's mostly useful for debugging.
Edit: Also, as Calamity has pointed out, ddraw will not be available in future Windows versions, so all my current and future testing has been and will be performed against D3D.
I understand the need to focus on d3d for a large part. The sad thing is that many of my tests show d3d to be inferior to ddraw.
As such I would like to raise a vote: Windows 7 is going to have extended support until 2020, so as long as ddraw is here (and as long as it's superior to d3d in certain aspects), please let us not forget about ddraw!
Apart from that, I'm -really- happy how the ASIO build is shaping up, great stuff, and great job from both you and Calamity! Thanks :)
Thanks a lot for your for tests! I don't think I would have attempted testing buffer sizes/latencies this low, so it's decidedly great to see this sort of stuff :)
Hi guys, sorry but I'm quite busy these days. Thanks a lot for the tests going on here. I'm happy to see a sort of agreement with Dr. Venom, finally.
Regarding the lower stability observed with -mt enabled, I think there's an explanation. In order to calculate current emulation speed, MAME measures the time elapsed once per frame. The exact point where this measurement is done is critical for the accuracy of the result. Usually, doing it right after we return from drawing is the best because the v-sync involved is more accurate than anything else. However, when running multithreaded, the draw operation is done in a separate blitting thread, while the main thread, where the speed measurement is to be performed, waits until it's signaled as ready by the blitting thread. This synchronization is done by means of an event object. The issue is, this mechanism requires the Windows scheduler to actually awake the main thread. This introduces an uncertainty relative to the time since we signal the event and the instant the thread is effectively awaken. This uncertainty doesn't happen when running single-threaded, as it will always take the same amount of cpu cycles to return from the drawing funtions back the main loop.
That said, the ultimate reason to use multithreading is to improve input response. So it should be determined if nowadays hardware still benefits from multithreading on this regard, as older hardware used to do. If this is still true, it might be possible to keep the multithreading just for input and force drawing and emulation in the same thread.
For the same reason, the advantage observed with ddraw seems to be directly related to the accuracy of the time it takes to ddraw to return. My understanding is this happens because ddraw involves no parallelization between cpu and gpu. That's what's behind the "superiority" of ddraw. If that is true, and we managed to completely break d3d parallelization, we'd achieve comparable results. The patch I posted some days ago had this purpuse, but it's poorly implemented. I'd like to do it *properly*. This means, it actually needs to grab data from the current modeline and make the timing dependent on absolute scanline numbers rather than uncertain "in-vblank" states. With that, it should really be very close to ddraw.
Thank you for the detailed explanation! I tried the patch, but didn't do extensive testing. I was about to, but it seemed that many ASIO issues could righted with the existing frame_delay code by setting m_speed with a slight holdoff (consistent speed for 1 second). With that said, with the above rationale and the results Dr.Venom has posted, I can't wait to get to trying it out again (currently no access to a proper GM rig). Also, when I tried the patch, I noticed static tearing, perhaps due to CRT Emudriver using a different line count scheme than the driver used for development?
-
Thank you for the detailed explanation! I tried the patch, but didn't do extensive testing. I was about to, but it seemed that many ASIO issues could righted with the existing frame_delay code by setting m_speed with a slight holdoff (consistent speed for 1 second). With that said, with the above rationale and the results Dr.Venom has posted, I can't wait to get to trying it out again (currently no access to a proper GM rig). Also, when I tried the patch, I noticed static tearing, perhaps due to CRT Emudriver using a different line count scheme than the driver used for development?
Oh, ok that totally changes things. I was assuming all recent tests had been done with the new frame delay code. Tearing was expected by the way. I was surprised no one reported it, now I see why. That's what will be hopefully fixed with the proper implementation (modeline dependent). Now Dr.Venom's results with d3d make more sense to me. You can't expect speed stability comparable to ddraw with the existing fd patch and d3d. To summarize, the ultimate goal of the changes I've been suggesting is exactly that: to get ddraw-accurate speed through d3d with minimum latency, so we can eventually get rid of ddraw. First attempt, with d3d9ex, so the manual v-sync hack was unnecessary (fail). Second attempt, accept the fact that manual v-sync hack is going to be required but do an extra syncronization before returning to improve speed accuracy (approximate ddraw-accurate speed by breaking parallelization).
-
Thank you for the detailed explanation! I tried the patch, but didn't do extensive testing. I was about to, but it seemed that many ASIO issues could righted with the existing frame_delay code by setting m_speed with a slight holdoff (consistent speed for 1 second). With that said, with the above rationale and the results Dr.Venom has posted, I can't wait to get to trying it out again (currently no access to a proper GM rig). Also, when I tried the patch, I noticed static tearing, perhaps due to CRT Emudriver using a different line count scheme than the driver used for development?
Oh, ok that totally changes things. I was assuming all recent tests had been done with the new frame delay code. Tearing was expected by the way. I was surprised no one reported it, now I see why. That's what will be hopefully fixed with the proper implementation (modeline dependent). Now Dr.Venom's results with d3d make more sense to me. You can't expect speed stability comparable to ddraw with the existing fd patch and d3d. To summarize, the ultimate goal of the changes I've been suggesting is exactly that: to get ddraw-accurate speed through d3d with minimum latency, so we can eventually get rid of ddraw. First attempt, with d3d9ex, so the manual v-sync hack was unnecessary (fail). Second attempt, accept the fact that manual v-sync hack is going to be required but do an extra syncronization before returning to improve speed accuracy (approximate ddraw-accurate speed by breaking parallelization).
I put in the new code in a test build if anyone wants to try it out! Although, keep in mind that static tearing will be present.
https://mega.nz/#!isRVgYzS!i4aaintTvS_NH0FhmqjE0AQxqt2J0gAYtTCZvd7QPhg (https://mega.nz/#!isRVgYzS!i4aaintTvS_NH0FhmqjE0AQxqt2J0gAYtTCZvd7QPhg) Edit: get link from a couple of posts below
Am I right in thinking that the tearing could be avoided by adding the vertical front porch of the current mode to the right hand side of the following comparison?
if (raster_status.ScanLine >= m_height)
-
Am I right in thinking that the tearing could be avoided by adding the vertical front porch of the current mode to the right hand side of the following comparison?
Actually, you need to check the sync_pulse + back_porch + height.
But you need to deal with interlaced modes where the porch lines must be divided by 2.
Also, forcing the synchronization after the present call to be done in-vblank is innacurate and may cause the retrace to be missed. It's better to check for the first absolute scanline line after retrace or higher. While in-vblank, getrasterstatus returns zero for whatever scanline number. When vblank ends and the new frame starts, the first scanline number is not 1 but sync_pulse + back_porch number of lines. Then the last line in the frame is sync_pulse + back_porch + height. Notice this is only valid for ATI. Intel cards label first line as 1 and last line as height.
(I need to check my notes to make sure, don't have them here right now)
-
Am I right in thinking that the tearing could be avoided by adding the vertical front porch of the current mode to the right hand side of the following comparison?
Sure. But you need to deal with interlaced modes where the porch lines must be divided by 2. Also, forcing the synchronization after the present call to be done in-vblank is innacurate and may cause the retrace to be missed. It's better to check for the first absolute scanline line after retrace or higher. While in-vblank, getrasterstatus returns zero for whatever scanline number. When vblank ends and the new frame starts, the first scanline number is not 1 but sync_pulse + back_porch number of lines. Then the last line in the frame is height + front_porch. Notice this is only valid for ATI. Intel cards label first line as 1 and last line as height.
Thanks :)
This stuff is way beyond me, I'm happy to experiment and test but I don't think I'll be able to do a proper implementation.
-
I haven't tested this, but it could be more or less like this:
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");
int last_scanline = m_switchres_mode && m_switchres_mode->vtotal?
m_switchres_mode->vactive + (m_switchres_mode->vtotal - m_switchres_mode->vbegin) / (m_switchres_mode->interlace?2:1) :
m_height;
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 >= last_scanline)
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");
int first_scanline = m_switchres_mode && m_switchres_mode->vtotal?
(m_switchres_mode->vtotal - m_switchres_mode->vbegin) / (m_switchres_mode->interlace?2:1) :
1;
while (raster_status.ScanLine <= first_scanline)
{
if ((*d3dintf->device.get_raster_status)(m_device, &raster_status) != D3D_OK)
break;
osd_printf_verbose("current_line: %d\n", raster_status.ScanLine);
}
}
}
-
I haven't tested this, but it could be more or less like this:
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");
int last_scanline = m_switchres_mode && m_switchres_mode->vtotal?
m_switchres_mode->vactive + (m_switchres_mode->vtotal - m_switchres_mode->vbegin) / (m_switchres_mode->interlace?2:1) :
m_height;
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 >= last_scanline)
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");
int first_scanline = m_switchres_mode && m_switchres_mode->vtotal?
(m_switchres_mode->vtotal - m_switchres_mode->vbegin) / (m_switchres_mode->interlace?2:1) :
1;
while (raster_status.ScanLine <= first_scanline)
{
if ((*d3dintf->device.get_raster_status)(m_device, &raster_status) != D3D_OK)
break;
osd_printf_verbose("current_line: %d\n", raster_status.ScanLine);
}
}
}
Thanks alot!
I currently don't have access to a testing rig (currently using a laptop with Intel integrated graphics), but I've added the code to the build posted below, will test tomorrow evening.
https://mega.nz/#!TlIEnCRA!W_6nh2B-UKVy6MNPZNm36aa1ZvMKpMDvHfif2rD9-WU
-
That's great! Thanks!
-
Hi guys,
I tested the latest build intealls posted, but unfortunately it doesn't seem to improve performance (materially). It still keeps producing a lot of audio underruns, and/or crashes the emulator at the latency where ddraw runs quite smoothly.
Regarding the lower stability observed with -mt enabled, I think there's an explanation. In order to calculate current emulation speed, MAME measures the time elapsed once per frame. The exact point where this measurement is done is critical for the accuracy of the result. Usually, doing it right after we return from drawing is the best because the v-sync involved is more accurate than anything else. However, when running multithreaded, the draw operation is done in a separate blitting thread, while the main thread, where the speed measurement is to be performed, waits until it's signaled as ready by the blitting thread. This synchronization is done by means of an event object. The issue is, this mechanism requires the Windows scheduler to actually awake the main thread. This introduces an uncertainty relative to the time since we signal the event and the instant the thread is effectively awaken. This uncertainty doesn't happen when running single-threaded, as it will always take the same amount of cpu cycles to return from the drawing funtions back the main loop.
Thanks for the explanation.
That said, the ultimate reason to use multithreading is to improve input response. So it should be determined if nowadays hardware still benefits from multithreading on this regard, as older hardware used to do. If this is still true, it might be possible to keep the multithreading just for input and force drawing and emulation in the same thread.
To my personal experience with the older gm's, there's a benefit from the input multithreading even on high-end hardware. If running the video in a single thread would end up being better for stabilty, then to me it definitely sound like a good idea to try and keep the multithreading just for input. If only to do extensive testing to see whether it really has a benefit or not.
Btw, this all assumes there's no releation to the video being multithreaded and that affecting input latency in some way?
Again, this is astonishing. What sound card/driver are you using? I don't think the cards I use with kX allow me to go to 48 without issues.
It's the ESI Juli@ XTe (see here (http://www.esi-audio.com/products/juliaxte/)) . I've tested quite some cards in the past, but this one has indeed the tightest ASIO driver I've encountered. The native driver also outperforms Asio4All in the speed/stability department. The great thing is the driver package is only 1.12MB and simply does what it must do. Apparently that's still possible on Windows :)
-asio_playback_rate can be used to force a resampling rate, using it will ignore the game speed so it's mostly useful for debugging.
Out of interest, what does the asio_callback_frequency actually measure? Do you know by any chance how it relates to the results of the Freqtest utility?
Edit: r1.5 contains a new batool version, with a drastically improved frequency calibration routine
Wow, this one does indeed perform a hell of a lot faster! With the old method I had to wait a while to average out (average of the different passes) on 48001.31. And this one converged quite fast to 48001.28
-
I tested the latest build intealls posted, but unfortunately it doesn't seem to improve performance (materially). It still keeps producing a lot of audio underruns, and/or crashes the emulator at the latency where ddraw runs quite smoothly.
Indeed, sorry for your time guys. There was an error in that implementation that made the second sync (the important for stability) unuseful. This one should do better. If it doesn't, then I'm definitely wrong.
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);
int last_scanline = m_switchres_mode && m_switchres_mode->vtotal?
m_switchres_mode->vactive + (m_switchres_mode->vtotal - m_switchres_mode->vbegin) / (m_switchres_mode->interlace?2:1) :
m_height;
int first_scanline = m_switchres_mode && m_switchres_mode->vtotal?
(m_switchres_mode->vtotal - m_switchres_mode->vbegin) / (m_switchres_mode->interlace?2:1) :
1;
// sync to VBLANK
osd_printf_verbose("\nwait vblank start\n");
if (window().machine().options().frame_delay() != 0 && ((video_config.triplebuf && window().fullscreen()) || video_config.waitvsync || video_config.syncrefresh))
{
D3DRASTER_STATUS raster_status;
memset (&raster_status, 0, sizeof(D3DRASTER_STATUS));
while (!raster_status.InVBlank)
{
if ((*d3dintf->device.get_raster_status)(m_device, &raster_status) != D3D_OK)
break;
osd_printf_verbose("current_line: %d\n", raster_status.ScanLine);
if (raster_status.ScanLine >= last_scanline)
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
osd_printf_verbose("wait vblank end\n");
if (window().machine().options().frame_delay() != 0 && ((video_config.triplebuf && window().fullscreen()) || video_config.waitvsync || video_config.syncrefresh))
{
D3DRASTER_STATUS raster_status;
memset (&raster_status, 0, sizeof(D3DRASTER_STATUS));
while (raster_status.ScanLine >= last_scanline || raster_status.ScanLine <= first_scanline)
{
if ((*d3dintf->device.get_raster_status)(m_device, &raster_status) != D3D_OK)
break;
osd_printf_verbose("current_line: %d\n", raster_status.ScanLine);
}
}
}
To my personal experience with the older gm's, there's a benefit from the input multithreading even on high-end hardware. If running the video in a single thread would end up being better for stabilty, then to me it definitely sound like a good idea to try and keep the multithreading just for input. If only to do extensive testing to see whether it really has a benefit or not.
Btw, this all assumes there's no releation to the video being multithreaded and that affecting input latency in some way?
Yes, I'll probably implement this. Having video and emulation in two threads is not required when running with syncrefresh. It is when using triplebuffer, because D3D9 does not support dropping frame and we have to simulate it. What we do when running with syncrefresh is to force both threads to be synchronized by means of an event object. I suspected it might have a performance penalty (in terms of speed stability) but your tests confirmed it. However that penalty hasn't been a problem until the more demanding ASIO audio has made it visible.
The video being multithreaded doesn't affect input latency. What affects latency is using the same thread to present v-synced video and process input.
-
Sorry to go off-topic. I'm using GM ASIO 0.163 r1.5 (with d3d9ex) and my sound card is a Creative Sound Blaster ZxR. I'm using the stock Creative driver because it's better than Asio4ALL for me.
I used batool64.exe --cp to set 6ms, which gives me the following in the log:
ASIO: Driver Creative SBZ Series ASIO initialized with latency 288,
sample rate 48000.00, compensated sample rate 48000.000000,
buffer size of 32768 samples
holdoff is 864 samples
This still produces a few overruns and underruns, but it's acceptable. I'm using -nosleep and priority 1 (not sure if it made a difference, but it can't be bad, right?), and HPET is disabled because it made no difference.
The last thing to do is to set a compensated sample rate. The issue I'm having is that batool64 0 runs for a couple of minutes and then closes abruptly. It starts out at about 477xx Hz and climbs almost immediately and logarithmically to about ~47990. The last number I see is ~47998.15 before command prompt just suddenly closes. Is 47998.15 then my compensated sample rate, or is something wrong? I tried the build posted here and get the same issue.
Also, about the "buffer size of 32768 samples", is that not implying another ~683ms of latency on top of the 6ms I set? "buffer size" sounds latency related. I read that devices have an inherent buffer size that is additional to the buffer size you set, so it would be 32768+288 samples to get the full latency value. It doesn't feel like I'm getting ~690ms of audio latency, but I'd still like to know what "buffer size" means in this context.
Finally, and perhaps "buffer size" is relevant to this next question as well, can someone please tell me what latency value at which it would no longer be worth using ASIO? It was mentioned in this thread that anything under 256 was good, and I'm wondering if my value of 288 is therefore not good, and I should go back to dsound with latency 1.0.
-
I tested the latest build intealls posted, but unfortunately it doesn't seem to improve performance (materially). It still keeps producing a lot of audio underruns, and/or crashes the emulator at the latency where ddraw runs quite smoothly.
Indeed, sorry for your time guys. There was an error in that implementation that made the second sync (the important for stability) unuseful. This one should do better. If it doesn't, then I'm definitely wrong.
No problem, hopefully your new adjustments will bring it on par.
@ intealls, would it be possibe to disable the continuous scanline number logging with the next release? Even though negligible, I guess it may have some negative impact on the test results.
To my personal experience with the older gm's, there's a benefit from the input multithreading even on high-end hardware. If running the video in a single thread would end up being better for stabilty, then to me it definitely sound like a good idea to try and keep the multithreading just for input. If only to do extensive testing to see whether it really has a benefit or not.
Yes, I'll probably implement this. Having video and emulation in two threads is not required when running with syncrefresh. It is when using triplebuffer, because D3D9 does not support dropping frame and we have to simulate it. What we do when running with syncrefresh is to force both threads to be synchronized by means of an event object. I suspected it might have a performance penalty (in terms of speed stability) but your tests confirmed it. However that penalty hasn't been a problem until the more demanding ASIO audio has made it visible.
Great that the tests were of help in confirming your suspicion. I can imagine that the penalty wasn't really an issue with directsound.
It will be interesting to see how only input on a separate thread will perform. Slightly off-topic, but if I ever wanted to buy a high-speed camera for doing the latency test with a led wired to the joystick, is there one which you would recommend? Or maybe there are things to keep in mind when looking for such a camera?
-
Slightly off-topic, but if I ever wanted to buy a high-speed camera for doing the latency test with a led wired to the joystick, is there one which you would recommend? Or maybe there are things to keep in mind when looking for such a camera?
Personally, I just use my work phone's slow motion mode. The iPhone 6 records at 240FPS, and I was using a 5S at 120FPS last year. I got a cheap mini-tripod as well to make recording easier. I'd suspect this is a fairly common feature on phones and cameras these days, but I haven't looked into it since I already had a solution in-hand.
-
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);
int last_scanline = m_switchres_mode && m_switchres_mode->vtotal?
m_switchres_mode->vactive + (m_switchres_mode->vtotal - m_switchres_mode->vbegin) / (m_switchres_mode->interlace?2:1) :
m_height;
int first_scanline = m_switchres_mode && m_switchres_mode->vtotal?
(m_switchres_mode->vtotal - m_switchres_mode->vbegin) / (m_switchres_mode->interlace?2:1) :
1;
// sync to VBLANK
osd_printf_verbose("\nwait vblank start\n");
if (window().machine().options().frame_delay() != 0 && ((video_config.triplebuf && window().fullscreen()) || video_config.waitvsync || video_config.syncrefresh))
{
D3DRASTER_STATUS raster_status;
memset (&raster_status, 0, sizeof(D3DRASTER_STATUS));
while (!raster_status.InVBlank)
{
if ((*d3dintf->device.get_raster_status)(m_device, &raster_status) != D3D_OK)
break;
osd_printf_verbose("current_line: %d\n", raster_status.ScanLine);
if (raster_status.ScanLine >= last_scanline)
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
osd_printf_verbose("wait vblank end\n");
if (window().machine().options().frame_delay() != 0 && ((video_config.triplebuf && window().fullscreen()) || video_config.waitvsync || video_config.syncrefresh))
{
D3DRASTER_STATUS raster_status;
memset (&raster_status, 0, sizeof(D3DRASTER_STATUS));
while (raster_status.ScanLine >= last_scanline || raster_status.ScanLine <= first_scanline)
{
if ((*d3dintf->device.get_raster_status)(m_device, &raster_status) != D3D_OK)
break;
osd_printf_verbose("current_line: %d\n", raster_status.ScanLine);
}
}
}
Here's a build with the latest changes!
https://mega.nz/#!DtQUkDwL!kZXlokfdyvTZUvFtOD4uNQZMGWfJFph-i4Ee_DvQ3xs (https://mega.nz/#!DtQUkDwL!kZXlokfdyvTZUvFtOD4uNQZMGWfJFph-i4Ee_DvQ3xs)
Slightly off-topic, but if I ever wanted to buy a high-speed camera for doing the latency test with a led wired to the joystick, is there one which you would recommend? Or maybe there are things to keep in mind when looking for such a camera?
Personally, I just use my work phone's slow motion mode. The iPhone 6 records at 240FPS, and I was using a 5S at 120FPS last year. I got a cheap mini-tripod as well to make recording easier. I'd suspect this is a fairly common feature on phones and cameras these days, but I haven't looked into it since I already had a solution in-hand.
I use a Playstation Eye camera, which can be had for cheap. It records 320x240@125 fps, so the picture is pretty crappy, but the videos can be recorded and viewed in VirtualDub so despite lacking image quality it's quite good to work with.
@ intealls, would it be possibe to disable the continuous scanline number logging with the next release? Even though negligible, I guess it may have some negative impact on the test results.
Removed in the build posted!
Sorry to go off-topic. I'm using GM ASIO 0.163 r1.5 (with d3d9ex) and my sound card is a Creative Sound Blaster ZxR. I'm using the stock Creative driver because it's better than Asio4ALL for me.
I used batool64.exe --cp to set 6ms, which gives me the following in the log:
ASIO: Driver Creative SBZ Series ASIO initialized with latency 288,
sample rate 48000.00, compensated sample rate 48000.000000,
buffer size of 32768 samples
holdoff is 864 samples
This still produces a few overruns and underruns, but it's acceptable. I'm using -nosleep and priority 1 (not sure if it made a difference, but it can't be bad, right?), and HPET is disabled because it made no difference.
I think you should be able to go lower than 6 ms with that card, try setting a buffer size of 128 to 192, currently that might actually improve the over-/underrun statistics. Also, don't put too much effort currently into trying to optimize, I'll most likely bring about changes come next release that will improve this statistic.
The last thing to do is to set a compensated sample rate. The issue I'm having is that batool64 0 runs for a couple of minutes and then closes abruptly. It starts out at about 477xx Hz and climbs almost immediately and logarithmically to about ~47990. The last number I see is ~47998.15 before command prompt just suddenly closes. Is 47998.15 then my compensated sample rate, or is something wrong? I tried the build posted here and get the same issue.
If it says 'rate has converged after x seconds', then that's the intended behavior, and your rate should be the one batool finds (in your case 47998.15).
Also, about the "buffer size of 32768 samples", is that not implying another ~683ms of latency on top of the 6ms I set? "buffer size" sounds latency related. I read that devices have an inherent buffer size that is additional to the buffer size you set, so it would be 32768+288 samples to get the full latency value. It doesn't feel like I'm getting ~690ms of audio latency, but I'd still like to know what "buffer size" means in this context.
No, this is an irrelevant bit information best removed. The holdoff parameter attemps to controls the actual latency.
Finally, and perhaps "buffer size" is relevant to this next question as well, can someone please tell me what latency value at which it would no longer be worth using ASIO? It was mentioned in this thread that anything under 256 was good, and I'm wondering if my value of 288 is therefore not good, and I should go back to dsound with latency 1.0.
Like I said, I think you should be able to go lower. If not, you could try using the integrated card with ASIO4ALL, since it will most likely perform better. And also, with a setting of 288, ASIO still lops off over 60 ms of latency (if things haven't changed since version 0.154 which this metric is based on).
Again, this is astonishing. What sound card/driver are you using? I don't think the cards I use with kX allow me to go to 48 without issues.
It's the ESI Juli@ XTe (see here (http://www.esi-audio.com/products/juliaxte/)) . I've tested quite some cards in the past, but this one has indeed the tightest ASIO driver I've encountered. The native driver also outperforms Asio4All in the speed/stability department. The great thing is the driver package is only 1.12MB and simply does what it must do. Apparently that's still possible on Windows :)
Thanks, might have to pick up one of those too.
-asio_playback_rate can be used to force a resampling rate, using it will ignore the game speed so it's mostly useful for debugging.
Out of interest, what does the asio_callback_frequency actually measure? Do you know by any chance how it relates to the results of the Freqtest utility?
You're right in that it's not really the best definition. It would be better to call it BASSASIO sample request frequency or similar, since the metric is how many samples BASSASIO requests each second. There might be a correlation between this and freqtest, I've done some preliminary tests but haven't seen anything decisive.
Edit: r1.5 contains a new batool version, with a drastically improved frequency calibration routine
Wow, this one does indeed perform a hell of a lot faster! With the old method I had to wait a while to average out (average of the different passes) on 48001.31. And this one converged quite fast to 48001.28
Yeah. :) It's a lot better. Also, it allows one to see what external factors might affect the request frequency in a reasonable way (HPET/QPC etc). For instance kX allows different sync methods for the ASIO driver, some of these seem to make the rate converge in a few seconds, but eats a lot more CPU than the standard one.
-
Super thanks for the assistance.
The ZxR has very weak performance in certain areas to be honest. My PC is a 4.2Ghz quad-core Ivy Bridge CPU with 16GB of pretty quick RAM, and I've disabled all power saving features and CPU sleep features as well as unnecessary processes. When I run audio sensitive applications and programs, I also disable the network adapter to reduce DPC latency even more. Despite all this, and despite letting the sound card run in exclusive mode with all sound processing off, I usually need >15ms latency for WASAPI exclusive and more than that for ASIO if I want to completely eliminate clicks and pops. It's a pretty common complaint with these cards. I would try on-board like you suggested, but the sound card does sound audibly better, so I can live with the latency.
I don't know if 'rate has converged after x seconds' does pop up. A line pops up, but it's there for about 1 frame before cmd closes. I assume that's what it says. So I put the 47998.15 into mame.ini and got slightly better results :). I used to get about 2 overruns and 12 underruns in 180 seconds with 288 samples. This time I got 0/10. I also tried 192 and 96 samples, and got 1/10 in 190 seconds, and 2/13 in 300 seconds respectively. Overall very similar results, but definitely better than before. I look forward to the next version of GM ASIO :)
-
I don't know if 'rate has converged after x seconds' does pop up. A line pops up, but it's there for about 1 frame before cmd closes. I assume that's what it says. So I put the 47998.15 into mame.ini and got slightly better results :). I used to get about 2 overruns and 12 underruns in 180 seconds with 288 samples. This time I got 0/10. I also tried 192 and 96 samples, and got 1/10 in 190 seconds, and 2/13 in 300 seconds respectively. Overall very similar results, but definitely better than before. I look forward to the next version of GM ASIO :)
Ah, I understand the problem. I should add a 'press enter to exit' to the tool. Thanks for reporting this.
Also, I haven't really tested the ASIO stuff with the setup you're using (120 Hz etc), so please report issues if you encounter them.
-
I haven't tested this, but it could be more or less like this:
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");
int last_scanline = m_switchres_mode && m_switchres_mode->vtotal?
m_switchres_mode->vactive + (m_switchres_mode->vtotal - m_switchres_mode->vbegin) / (m_switchres_mode->interlace?2:1) :
m_height;
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 >= last_scanline)
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");
int first_scanline = m_switchres_mode && m_switchres_mode->vtotal?
(m_switchres_mode->vtotal - m_switchres_mode->vbegin) / (m_switchres_mode->interlace?2:1) :
1;
while (raster_status.ScanLine <= first_scanline)
{
if ((*d3dintf->device.get_raster_status)(m_device, &raster_status) != D3D_OK)
break;
osd_printf_verbose("current_line: %d\n", raster_status.ScanLine);
}
}
}
Thanks alot!
I currently don't have access to a testing rig (currently using a laptop with Intel integrated graphics), but I've added the code to the build posted below, will test tomorrow evening.
https://mega.nz/#!TlIEnCRA!W_6nh2B-UKVy6MNPZNm36aa1ZvMKpMDvHfif2rD9-WU
And here are my results (all without multithreading)! Be sure to look at the scale of the speed percentage, Octave wasn't being consistent with this.
From what I can see, there's a striking similarity between the new d3d code and ddraw, at least for the games I've tested. ddraw seems to produce _slightly_ more consistent speeds (however, they're miniscule, look at the scale!), I don't think this will make any difference at all in regards to audio performance. Other factors might factor in of course but I don't think the speed variation will make any difference.
This has prompted me to do a new test - add the d3d9ex code (I think I'll add this permanently to the ASIO patch to make it W7 only, ASIO seems to be pretty crappy in XP anyway), remove the m_speed hack currently in the 0.163 build, and do a test with the new frame_delay code (with/without -mt).
-
ASIO seems to be pretty crappy in XP anyway
Haha! Tell that to the thousands of musicians who were loath to give up their nicely tune XP for Win 7 when it first came out. ;)
For what it's worth, I can still get lower latency on my Lenovo W500 laptop and RME Fireface UC interface under XP than 7 when processing live guitar signals. The DPC latency when booting to XP is still lower than W7 with my rig.
Anyway, I digress... ;)
Keep up the good work! I have been following this really closely. I have a bunch of quality ASIO devices (Edirol UA-25, M Audio Audiophile 2496, RME Fireface UC and RME Fireface 400). Obviously, the quality of some of these devices (esp. RME) would be overkill for MAME but I have 3 NOS Audiophile cards that I plan on using in my cabs once you've got this nutted. :)
I suppose I should get off ---my bottom--- and help with the testing since I have all that hardware sitting here... ;D
-
ASIO seems to be pretty crappy in XP anyway
Haha! Tell that to the thousands of musicians who were loath to give up their nicely tune XP for Win 7 when it first came out. ;)
For what it's worth, I can still get lower latency on my Lenovo W500 laptop and RME Fireface UC interface under XP than 7 when processing live guitar signals. The DPC latency when booting to XP is still lower than W7 with my rig.
Anyway, I digress... ;)
Keep up the good work! I have been following this really closely. I have a bunch of quality ASIO devices (Edirol UA-25, M Audio Audiophile 2496, RME Fireface UC and RME Fireface 400). Obviously, the quality of some of these devices (esp. RME) would be overkill for MAME but I have 3 NOS Audiophile cards that I plan on using in my cabs once you've got this nutted. :)
I suppose I should get off ---my bottom--- and help with the testing since I have all that hardware sitting here... ;D
I should probably clarify that to 'From my (fairly limited) testing, ASIO seems to be pretty crappy with ASIO4ALL/kX in XP anyway' :) I seem to remember getting better results on XP with an Audigy 2/Creative driver. But this was a couple of years ago.
All testing is greatly appreciated! The more drivers/cards that can be tested the better. However, it seems that some of the cards you have will cost more than a fast, brand new GM system, so I don't know how representative those particular tests will be for the majority of users. :)
Edit: However, it might be extremely interesting to know what the calibration frequency of those devices might turn out to.
-
However, it seems that some of the cards you have will cost more than a fast, brand new GM system, so I don't know how representative those particular tests will be for the majority of users. :)
That's true. I guess the advantage for testing is that you know that RME aren't going to give you a half-baked driver so you can eliminate the driver from the equation when testing. :)
This ASIO thing is definitely worth pursuing though... when it's done right, the low latency afforded by a decent ASIO driver and compatible application is a pretty magic thing. For musicians, it changed everything. With a good setup, we're talking less than 10 ms for the round trip (input, processing, output). Musicians are pretty intimate with their instruments so they can "feel" the latency much more readily than your average gamer (not that any of us are really "average gamers"... pursuing obsolete technology (CRTs) and games (arcade and retro console) ;) ).
I think your ASIO initiative is definitely a very good one. It's the audio equivalent of what is being chased with frame delay and low latency input. The advantage with the ASIO adventure is that it's a proven technology and there are so many examples of great implementations (audio software, not games). The point is that it can definitely be done. The MAME case seems to have it's challenges though...
ASIO4ALL is a really neat tool. Same with the KX stuff. However, I think the thing to look for would be an outmoded pro audio card that is now reasonably cheap (such as the M-Audio card I mentioned or the ESI card Dr Venom mentioned). These kind of cards are no longer "state of the art" but are still miles ahead of average consumer cards in terms of quality. The real benefit though would be the stable drivers that would have come about after much testing from highly demanding users (high latency, glitches, drop-outs, flaky drivers aren't tolerated by producers/musicians).
Keep up the good work! I'll try to get around to some testing soon. :)
-
However, it seems that some of the cards you have will cost more than a fast, brand new GM system, so I don't know how representative those particular tests will be for the majority of users. :)
That's true. I guess the advantage for testing is that you know that RME aren't going to give you a half-baked driver so you can eliminate the driver from the equation when testing. :)
Absolutely, I edited my above post to add that it might be very interesting to see what the calibration frequency of these cards turn out to be.
I think your ASIO initiative is definitely a very good one. It's the audio equivalent of what is being chased with frame delay and low latency input. The advantage with the ASIO adventure is that it's a proven technology and there are so many examples of great implementations (audio software, not games). The point is that it can definitely be done. The MAME case seems to have it's challenges though...
ASIO4ALL is a really neat tool. Same with the KX stuff. However, I think the thing to look for would be an outmoded pro audio card that is now reasonably cheap (such as the M-Audio card I mentioned or the ESI card Dr Venom mentioned). These kind of cards are no longer "state of the art" but are still miles ahead of average consumer cards in terms of quality. The real benefit though would be the stable drivers that would have come about after much testing from highly demanding users (high latency, glitches, drop-outs, flaky drivers aren't tolerated by producers/musicians).
Keep up the good work! I'll try to get around to some testing soon. :)
Thanks! The implementation currently uses BASSASIO, which is actually very straightforward to use. I currently cannot find an incentive to use anything else. It's possible to use an external resampling lib/write a resampler and use that with WASAPI/Steinberg ASIO SDK but I currently don't see the point, there's still issues that needs to be worked out before doing anything else. WASAPI might be nice since it's an official Windows thing but most of the issues that are relevant for ASIO will probably apply for WASAPI as well. Also, ASIO4ALL seems to cover general sound card support pretty well.
-
From what I can see, there's a striking similarity between the new d3d code and ddraw, at least for the games I've tested. ddraw seems to produce _slightly_ more consistent speeds (however, they're miniscule, look at the scale!), I don't think this will make any difference at all in regards to audio performance. Other factors might factor in of course but I don't think the speed variation will make any difference.
Well, this is great! I understand that you didn't get any tearing either. Looks like ddraw might be a bit more consistent still probably since it's doing the whole thing in kernel mode before returning, while the multiple calls we do in d3d involve switching between kernel and user mode which has an overhead, although this should be negligible as hardware evolves. It's certainly an advantage to have control over the current scanline, I think we'll manage to use that information for something interesting.
This has prompted me to do a new test - add the d3d9ex code (I think I'll add this permanently to the ASIO patch to make it W7 only, ASIO seems to be pretty crappy in XP anyway), remove the m_speed hack currently in the 0.163 build, and do a test with the new frame_delay code (with/without -mt).
With regards to LCD monitors, it is nice to have the d3d9ex mode available, since fd causes static tearing with those. It's actually not a matter of the monitor being LCD, it's the scaling involved and the time it takes (if it's longer than the retrace) what causes the tearing. So this also happens on CRT monitors at "high" resolutions when using a slow card. If the card is fast enough you don't get tearing even at high resolutions, for instance I don't get any tearing at 2560x1600 with an R9 270 and fd. But as soon as I use hlsl, I get lots of tearing, since the time it takes to render a frame increases until it doesn't "fit" in the retrace anymore.
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:
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.
I'm not sure if it's good to remove the m_speed thing however. For the case of typical LCD monitors (again), when you're forced to run everything at 60 Hz, this will cause sound problems I believe.
-
Thanks for this version of GM, intealls! I've only just gotten round to trying it and am very impressed. The sound lag in certain games - like Pac-Man - was bugging me but ASIO GM seems to have pretty much nailed the problem. Thanks again! :applaud:
-
I don't know if 'rate has converged after x seconds' does pop up. A line pops up, but it's there for about 1 frame before cmd closes. I assume that's what it says. So I put the 47998.15 into mame.ini and got slightly better results :). I used to get about 2 overruns and 12 underruns in 180 seconds with 288 samples. This time I got 0/10. I also tried 192 and 96 samples, and got 1/10 in 190 seconds, and 2/13 in 300 seconds respectively. Overall very similar results, but definitely better than before. I look forward to the next version of GM ASIO :)
Ah, I understand the problem. I should add a 'press enter to exit' to the tool. Thanks for reporting this.
Also, I haven't really tested the ASIO stuff with the setup you're using (120 Hz etc), so please report issues if you encounter them.
I'll be sure to let you know if I find anything janky.
I also want to add my thanks for your ASIO implementation. Low latency and highly configurable audio is honestly one of the most important features of emulation for me, and it's a feature of all my favourite emulators. It was one aspect of MAME which I always felt was sorely lacking. I have a game which exists on PS2 and CPS3, and while the PS2 version is technically inferior and has more input lag, my PS2 emulator at least has WASAPI support and therefore had noticeably less audio lag on this game until GM ASIO. As much as I like low input lag, I think it means little without low audio lag.
-
Slightly off-topic, but if I ever wanted to buy a high-speed camera for doing the latency test with a led wired to the joystick, is there one which you would recommend? Or maybe there are things to keep in mind when looking for such a camera?
Personally, I just use my work phone's slow motion mode. The iPhone 6 records at 240FPS, and I was using a 5S at 120FPS last year. I got a cheap mini-tripod as well to make recording easier. I'd suspect this is a fairly common feature on phones and cameras these days, but I haven't looked into it since I already had a solution in-hand.
Thanks, that sounds like a great option. I've been considering upgrading my iPhone for some time now, and this slow motion mode may be the final push :). The mini-tripod looks like a great addition as well!
Here's a build with the latest changes!
https://mega.nz/#!DtQUkDwL!kZXlokfdyvTZUvFtOD4uNQZMGWfJFph-i4Ee_DvQ3xs (https://mega.nz/#!DtQUkDwL!kZXlokfdyvTZUvFtOD4uNQZMGWfJFph-i4Ee_DvQ3xs)
I've done the tests with the genesis driver. The positive thing is that the results for d3d are marginally better with this latest release, but unfortunately it still doesn't come close to ddraw. By and large the results I posted for the previous build still hold (see here (http://forum.arcadecontrols.com/index.php/topic,142143.msg1520186.html#msg1520186)).
To sort of summarize, I've attached three pictures. In the first two the marginal improvement for d3d versus previous release d3d can be seen. The last picture shows the more stable results for ddraw.
And here are my results (all without multithreading)! Be sure to look at the scale of the speed percentage, Octave wasn't being consistent with this.
Intealls, could you possibly also test the genesis driver d3d versus ddraw on your side (using -resolution 1280x0)? I'm curious whether you find the same differences. Given your other results (ddraw only marginally better than d3d) I'm wondering whether the genesis driver is somehow the odd one out?
With regards to the results you posted for gunforc2, pbobble and the others. Is it a coincidence that they are all running at 99.99%? I'm a bit surprised by this, given that they are running different modelines. Because of this, I would expect a bit more random pattern of values above and below 100% that the emulation is being forced to. It could still be coincidence of course.
I also found another testcase with outrun. With this game it keeps increasing the samples in the buffer at a steady pace before falling back (same for d3d and ddraw). See the attached picture!
-
Thanks, that sounds like a great option. I've been considering upgrading my iPhone for some time now, and this slow motion mode may be the final push :).
Depending on which model you have, you might be able to get at least 60FPS through a 3rd-party app. I did this with the iPhone 5.
-
I've done the tests with the genesis driver. The positive thing is that the results for d3d are marginally better with this latest release, but unfortunately it still doesn't come close to ddraw.
That's far from being a positive thing :)
I'm totally missing something here. If you didn't have the ddraw results I'll be looking for something between the video and audio updates that took a slightly different amount of time for each frame as the possible cause. But seeing that ddraw keeps everything so stable opposite to d3d definitely points to the video api, and that's something I really don't understand, since the getrasterstatus call should force an the exact amount of time per frame just like ddraw. So the only thing I can think of right now is a combination of the gpu and video drivers. The fact is that my testing has been done with two cards: HD 6450 and R9 270 and for both of them I got the scanlines to be reported consistenly per frame. I didn't test any HD 4xxx + CRT Emudriver (my testing rig uses newer hardware now as I'm doing other "experiments"). It'd be good to know what card intealls is testing with. It's important to enable the scanline log per frame at least temporarily (send it to a file), and check whether "vblank_end" exists consistenly at the same scanline number (it'll take a few frames to stabilize). If it does (+-1 line is ok) then definitely I don't understand what's going on.
-
I've done the tests with the genesis driver. The positive thing is that the results for d3d are marginally better with this latest release, but unfortunately it still doesn't come close to ddraw.
That's far from being a positive thing :)
I'm totally missing something here. If you didn't have the ddraw results I'll be looking for something between the video and audio updates that took a slightly different amount of time for each frame as the possible cause. But seeing that ddraw keeps everything so stable opposite to d3d definitely points to the video api, and that's something I really don't understand, since the getrasterstatus call should force an the exact amount of time per frame just like ddraw. So the only thing I can think of right now is a combination of the gpu and video drivers. The fact is that my testing has been done with two cards: HD 6450 and R9 270 and for both of them I got the scanlines to be reported consistenly per frame. I didn't test any HD 4xxx + CRT Emudriver (my testing rig uses newer hardware now as I'm doing other "experiments"). It'd be good to know what card intealls is testing with. It's important to enable the scanline log per frame at least temporarily (send it to a file), and check whether "vblank_end" exists consistenly at the same scanline number (it'll take a few frames to stabilize). If it does (+-1 line is ok) then definitely I don't understand what's going on.
I'll test/add this, but on a whole, but I don't think the speed_percent stability is going to be a problem. Even if it's not as stable as ddraw, I think it's definitely good enough. Also, I'm currently testing doing audio updates from video_manager::frame_update (instead of the default periodic timer updates), which might even make the speed_percent metric redundant, since I could probably deduce the dot-clock granulated frame rate from this instead (perhaps not as quickly though). Though it would be nice to have access the metric if it's already computed somewhere. Also, the sound output modules are not given access to speed_percent per default anymore since somewhere around 0.159/0.160.
The card used is a RV730 (4650/4670?).
And here are my results (all without multithreading)! Be sure to look at the scale of the speed percentage, Octave wasn't being consistent with this.
Intealls, could you possibly also test the genesis driver d3d versus ddraw on your side (using -resolution 1280x0)? I'm curious whether you find the same differences. Given your other results (ddraw only marginally better than d3d) I'm wondering whether the genesis driver is somehow the odd one out?
With regards to the results you posted for gunforc2, pbobble and the others. Is it a coincidence that they are all running at 99.99%? I'm a bit surprised by this, given that they are running different modelines. Because of this, I would expect a bit more random pattern of values above and below 100% that the emulation is being forced to. It could still be coincidence of course.
Thanks again for your tests! I think it's accurate, but I'll measure the vsync lead with the games tested to make sure. I'll also test the genesis driver with 1280x0.
I also found another testcase with outrun. With this game it keeps increasing the samples in the buffer at a steady pace before falling back (same for d3d and ddraw). See the attached picture!
I'm testing a fix for this now. Normally a timer is set for audio updates (50 times/second, ASIO changed this to first 125 then 60), I've disabled this and do the audio update after the end-of-frame update. This makes buffer handling a whole lot easier, however I do need to make sure that this has no negative side effects. Also, I think now is the time to get a better understanding of how the sound system works, since I think there's intermediary buffering going on, which may or may not be driver-dependent. I find it difficult to believe that the actual pbobble hardware would buffer as many samples as shown in the topmost plot in this post http://forum.arcadecontrols.com/index.php/topic,141869.msg1469093.html#msg1469093 (http://forum.arcadecontrols.com/index.php/topic,141869.msg1469093.html#msg1469093), however actual hardware tests would need to be conducted. I've got a NeoGeo sitting here that I haven't hooked up yet, to use for comparison (though not with pbobble). Anyway, I redid the tests yesterday, and frame_delay does chop off a bit allowing the latency to go to about ~60 ms (leaving the actual latency produced to something in the vicinity of ~55 ms, since a couple of milliseconds can be attributed to USB input lag, plot two posts down).
Also, I managed to get kX to accept a 48 buffer size without dropouts by changing the sync method to Kernel/SMP. Below is an Outrun (hardihar) with fd6 (new fd code) and -mt with the 48 buffer size setting. What can be seen is that the buffer is stably running at about 120 to 160 samples. This means a worst case latency of (160 + 48)/48 = ~4.3 ms, if no intermediary buffering is going on (which I think is). So the ASIO functionality itself is not producing any noteworthy latency additions in this example. Also speed_percent appears to be swinging a bit (again, mind the scale), but as can be seen this doesn't affect the audio performance at all. There's currently a backoff in place which only accepts a new speed_percent value if it's being fairly consistently reported for about half a second.
-
Also, I'm currently testing doing audio updates from video_manager::frame_update (instead of the default periodic timer updates)
Normally a timer is set for audio updates (50 times/second, ASIO changed this to first 125 then 60), I've disabled this and do the audio update after the end-of-frame update.
Brilliant. I was struggling to understand at what point in baseline code the audio update is performed, I wasn't aware you've modified it in you build to put it exactly in the right point (IMHO).
This makes buffer handling a whole lot easier, however I do need to make sure that this has no negative side effects. Also, I think now is the time to get a better understanding of how the sound system works
Definitely, that's true for me, I should dedicate some time to understand the audio part as I'm totally clueless about it and how it relates to the video.
One wants to believe that MAMEdevs had a good reason to make audio update asynchronous with regards to video, maybe some hardware requires it to be like that (we focus almost exclusively in 80-90's raster video games, but what about vectors, etc).
But let's don't forget there's always a remote possibility that it wasn't such a good idea and it only made sense from a software engineering point of view.
Also speed_percent appears to be swinging a bit (again, mind the scale), but as can be seen this doesn't affect the audio performance at all. There's currently a backoff in place which only accepts a new speed_percent value if it's being fairly consistently reported for about half a second.
Maybe the m_speed patch could help with the swinging? (anyway the precision on m_speed would be only 0.999 so that variation wouldn't be registered)
Another approach is what they do in RetroArch. Instead of looking at the speed, they check the amount of remaining samples in the buffer, and modify the sample frequency based on that.
-
I've done the tests with the genesis driver. The positive thing is that the results for d3d are marginally better with this latest release, but unfortunately it still doesn't come close to ddraw.
That's far from being a positive thing :)
I'm totally missing something here. If you didn't have the ddraw results I'll be looking for something between the video and audio updates that took a slightly different amount of time for each frame as the possible cause. But seeing that ddraw keeps everything so stable opposite to d3d definitely points to the video api, and that's something I really don't understand, since the getrasterstatus call should force an the exact amount of time per frame just like ddraw. So the only thing I can think of right now is a combination of the gpu and video drivers. The fact is that my testing has been done with two cards: HD 6450 and R9 270 and for both of them I got the scanlines to be reported consistenly per frame. I didn't test any HD 4xxx + CRT Emudriver (my testing rig uses newer hardware now as I'm doing other "experiments"). It'd be good to know what card intealls is testing with. It's important to enable the scanline log per frame at least temporarily (send it to a file), and check whether "vblank_end" exists consistenly at the same scanline number (it'll take a few frames to stabilize). If it does (+-1 line is ok) then definitely I don't understand what's going on.
Do you mean vblank_end() in screen or vblank end in the fd new code? vblank end in the new fd code seems to exit very consistently. I moved the printouts out of the loops as per the code posted below, and got the result in the attached log. frame_delay is set to 7 (pbobble).
Also did yet another comparison (though not as lengthy) attached.
// sync to VBLANK
osd_printf_verbose("\nwait vblank start\n");
if (window().machine().options().frame_delay() != 0 && ((video_config.triplebuf && window().fullscreen()) || video_config.waitvsync || video_config.syncrefresh))
{
D3DRASTER_STATUS raster_status;
memset (&raster_status, 0, sizeof(D3DRASTER_STATUS));
while (!raster_status.InVBlank)
{
if ((*d3dintf->device.get_raster_status)(m_device, &raster_status) != D3D_OK)
break;
if (raster_status.ScanLine >= last_scanline)
break;
}
osd_printf_verbose("current_line: %d\n", raster_status.ScanLine);
}
// 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
osd_printf_verbose("wait vblank end\n");
if (window().machine().options().frame_delay() != 0 && ((video_config.triplebuf && window().fullscreen()) || video_config.waitvsync || video_config.syncrefresh))
{
D3DRASTER_STATUS raster_status;
memset (&raster_status, 0, sizeof(D3DRASTER_STATUS));
while (raster_status.ScanLine >= last_scanline || raster_status.ScanLine <= first_scanline)
{
if ((*d3dintf->device.get_raster_status)(m_device, &raster_status) != D3D_OK)
break;
}
osd_printf_verbose("current_line: %d\n", raster_status.ScanLine);
}
-
Do you mean vblank_end() in screen or vblank end in the fd new code? vblank end in the new fd code seems to exit very consistently.
Yeah I meant that vblank end. It shows line 28 all the time, which is right. I still don't get why ddraw would do any better here, unless sub-scanline precision matters.
If I get this right, 48000/15750 = 3,04 samples per scanline (is this right?)
So let's say ddraw is able to exit vblank end more accurately than d3d, even so the maximum mismatch would be 3 samples per frame (probably less). Would that mismatch, accumulated after some frames, explain the variability you get?
-
To sort of summarize, I've attached three pictures. In the first two the marginal improvement for d3d versus previous release d3d can be seen. The last picture shows the more stable results for ddraw.
This isn't completely fair. The scales on the genesis new-fd/genesis ddraw are different, with the d3d one going from 0.99995 to 1.00015 and ddraw going from ~0.89 to 1.02. Although when comparing genesis new-fd with outrun, ddraw does seem a bit more stable.
Also, I'm currently testing doing audio updates from video_manager::frame_update (instead of the default periodic timer updates)
Normally a timer is set for audio updates (50 times/second, ASIO changed this to first 125 then 60), I've disabled this and do the audio update after the end-of-frame update.
Brilliant. I was struggling to understand at what point in baseline code the audio update is performed, I wasn't aware you've modified it in you build to put it exactly in the right point (IMHO).
Thanks :) After the previous discussion a while back about emulation audio latency it certainly seemed to make sense putting it there.
This makes buffer handling a whole lot easier, however I do need to make sure that this has no negative side effects. Also, I think now is the time to get a better understanding of how the sound system works
Definitely, that's true for me, I should dedicate some time to understand the audio part as I'm totally clueless about it and how it relates to the video.
One wants to believe that MAMEdevs had a good reason to make audio update asynchronous with regards to video, maybe some hardware requires it to be like that (we focus almost exclusively in 80-90's raster video games, but what about vectors, etc).
But let's don't forget there's always a remote possibility that it wasn't such a good idea and it only made sense from a software engineering point of view.
Absolutely, hopefully it won't affect anything negatively. But there are a lot of drivers just like you say, and we can't test them all. :)
Also speed_percent appears to be swinging a bit (again, mind the scale), but as can be seen this doesn't affect the audio performance at all. There's currently a backoff in place which only accepts a new speed_percent value if it's being fairly consistently reported for about half a second.
Maybe the m_speed patch could help with the swinging? (anyway the precision on m_speed would be only 0.999 so that variation wouldn't be registered)
Another approach is what they do in RetroArch. Instead of looking at the speed, they check the amount of remaining samples in the buffer, and modify the sample frequency based on that.
I've been testing linear fitting of (incoming minus outgoing) samples (which is probably overkill, but simple enough to do), which would roll the speed_percent and the calibration frequency into one metric. I need to check out how they do it in RetroArch, but I suspect low latency audio will put tighter demands on the adjustment routine (as it does with everything else :) ).
Do you mean vblank_end() in screen or vblank end in the fd new code? vblank end in the new fd code seems to exit very consistently.
Yeah I meant that vblank end. It shows line 28 all the time, which is right. I still don't get why ddraw would do any better here, unless sub-scanline precision matters.
If I get this right, 48000/15750 = 3,04 samples per scanline (is this right?)
So let's say ddraw is able to exit vblank end more accurately than d3d, even so the maximum mismatch would be 3 samples per frame (probably less). Would that mismatch, accumulated after some frames, explain the variability you get?
I think 48000 * (dot-clock granulated refresh / game refresh) / 15750 is the amount of samples. So (48000 * speed_percent) / 15750. So something very close to 3.
If you mean the variability in the above plots, I think that can be explained. Right now, I believe that the (very small) variations in buffer size in the above plots show a phase discrepancy between the BASSASIO callback and the audio update routine. I've attached a zoomed in plot. One can see that the maximum variation appears to be somewhere around 48 (note the first time it goes to 160, then down to ~115).
The main thing causing problems is the intermittent sample delay generation, but I haven't seen this in a while, and not with the m_speed hack + new fd code. I've also noticed that changing m_speed too often will cause some problems but I really need to investigate this further, especially with the new additions (new fd code + audio update at end of frame). I seem to be able to reproduce this with the old fd code, but I haven't seen it with the new. It's the problem outlined in this http://forum.arcadecontrols.com/index.php/topic,142143.msg1518722.html#msg1518722 (http://forum.arcadecontrols.com/index.php/topic,142143.msg1518722.html#msg1518722) post.
Edit: I threw some statistics onto my measurements (gunforc2, pbobble etc) and came up with the result below
file: u:\vicosku_new\new_fd_code\2\gunforc2_fd6_d3d_7.log
std dev: 0.0000061
mean: 0.9989841
max: 0.9990220
min: 0.9989440
max - min: 0.0000780
file: u:\vicosku_new\new_fd_code\2\gunforc2_fd6_ddraw_7.log
std dev: 0.0000046
mean: 0.9989841
max: 0.9990140
min: 0.9989570
max - min: 0.0000570
file: u:\vicosku_new\new_fd_code\2\neodrift_fd6_d3d_7.log
std dev: 0.0000061
mean: 0.9996173
max: 0.9996590
min: 0.9995700
max - min: 0.0000890
file: u:\vicosku_new\new_fd_code\2\neodrift_fd6_ddraw_7.log
std dev: 0.0000046
mean: 0.9996173
max: 0.9996370
min: 0.9995980
max - min: 0.0000390
file: u:\vicosku_new\new_fd_code\2\pbobble_fd7_d3d_7.log
std dev: 0.0000066
mean: 0.9989841
max: 0.9990190
min: 0.9989510
max - min: 0.0000680
file: u:\vicosku_new\new_fd_code\2\pbobble_fd7_ddraw_7.log
std dev: 0.0000050
mean: 0.9989841
max: 0.9990160
min: 0.9989540
max - min: 0.0000620
file: u:\vicosku_new\new_fd_code\2\sf2hf_fd7_d3d_7.log
std dev: 0.0000059
mean: 0.9997785
max: 0.9998060
min: 0.9997480
max - min: 0.0000580
file: u:\vicosku_new\new_fd_code\2\sf2hf_fd7_ddraw_7.log
std dev: 0.0000045
mean: 0.9997786
max: 0.9998040
min: 0.9997570
max - min: 0.0000470
As one can see, the differences are not very big.
Edit again:
I just did a genesis run (Mega Turrican, super resolution 1280x0 with two "resolution switches" (Data East logo -> title screen -> gameplay)), with the following results:
file: u:\vicosku_new\new_fd_code\genesis\genesis_d3d.log
std dev: 0.0000160
mean: 1.0004094
max: 1.0004600
min: 1.0003600
max - min: 0.0001000
file: u:\vicosku_new\new_fd_code\genesis\genesis_ddraw.log
std dev: 0.0000160
mean: 1.0004096
max: 1.0004600
min: 1.0003700
max - min: 0.0000900
They are strikingly similar. Attached two plots as well, sorry for the crappy handwriting but snipping tool doesn't offer proper text. Also they were done with frame_delay 5.
Edit again again:
Did a 10 minute run of Mega Turrican to find out if the resolution switches would cause any issues: and no. No underruns noted.
file: u:\vicosku_new\asio.log (Mega Turrican 10 min run)
std dev: 0.0000161
mean: 1.0001045
max: 1.0001900
min: 1.0000200
max - min: 0.0001700
Edit just one more time:
I've uploaded the build used for these tests to here https://mega.nz/#!jsREGTKT!v0lQ2TUziRnFrOpzEn5VuYo3i5G8ShFKnXNjlTG7i1w (https://mega.nz/#!jsREGTKT!v0lQ2TUziRnFrOpzEn5VuYo3i5G8ShFKnXNjlTG7i1w) , but it's really, really broken and should only be used to check my statements above. Also, with this particular build, asio_holdoff works the other way around, and should be set to 672 with a latency setting of 48. Also I've attached the Octave script used for calculating mean/max etc.
-
Right now, I believe that the (very small) variations in buffer size in the above plots show a phase discrepancy between the BASSASIO callback and the audio update routine.
Alright I see what you mean, makes total sense.
I'm eager to see if Dr.Venom can replicate your results with the genesis driver.
-
This isn't completely fair. The scales on the genesis new-fd/genesis ddraw are different, with the d3d one going from 0.99995 to 1.00015 and ddraw going from ~0.89 to 1.02. Although when comparing genesis new-fd with outrun, ddraw does seem a bit more stable.
You're absolutely right. I only realized just now how deceptive the scaling on the chart actually is. What I did was re-run both tests, and then cut off the first 32 readings from the log (which causes the spike from 0.89 to 1.02). I've attached both charts, which shows that they are much more similar now. Looking at the sample buffer stability, possibly even in favour of d3d!
Edit: I've just noticed your edited post with additional results for the genesis driver. I'm glad we got this part sorted!
That only leaves us with the "lowest possible latency test" comparison (as I reported earlier).
When using ddraw with the genesis driver I can get as low as 48 with a holdoff of 528, with zero over-/underruns. When running this setting with d3d, the emulator either produces a continuous stream of underruns (small sample quoted below) and/or crashes. This remains until raising the holdoff to 816. In other words a 6ms "lowest possible audio latency" difference between ddraw and d3d.
I'm not sure how this test will hold up for other drivers though. It's just that if ddraw allows me to go to a holdoff of 528 for the genesis driver, I want to be able to do that with d3d too! ;)
Intealls, could you possibly also run this "lowest possible latency test" to compare d3d and ddraw performance with the genesis driver for your system? I'm curious whether you'll get comparable results. It may provide a last missing link?
ASIO: Resync underrun at about update 224, speed: 1.000063
ASIO: Reverting head -64 counts, just got 800 samples
ASIO: Resync underrun at about update 225, speed: 1.000063
ASIO: Reverting head -64 counts, just got 800 samples
ASIO: Resync underrun at about update 226, speed: 1.000063
ASIO: Reverting head -64 counts, just got 800 samples
ASIO: Resync underrun at about update 227, speed: 1.000063
ASIO: Reverting head -64 counts, just got 800 samples
ASIO: Resync underrun at about update 228, speed: 1.000063
ASIO: Reverting head -64 counts, just got 800 samples
ASIO: Resync underrun at about update 229, speed: 1.000063
ASIO: Reverting head -64 counts, just got 800 samples
ASIO: Resync underrun at about update 230, speed: 1.000063
Edit just one more time:
I've uploaded the build used for these tests to here https://mega.nz/#!jsREGTKT!v0lQ2TUziRnFrOpzEn5VuYo3i5G8ShFKnXNjlTG7i1w (https://mega.nz/#!jsREGTKT!v0lQ2TUziRnFrOpzEn5VuYo3i5G8ShFKnXNjlTG7i1w) , but it's really, really broken and should only be used to check my statements above. Also, with this particular build, asio_holdoff works the other way around, and should be set to 672 with a latency setting of 48. Also I've attached the Octave script used for calculating mean/max etc.
EDIT: What do you exactly mean with "the other way around". If I have the driver set to a latency of 48 samples, can I still set the asio_holdoff to 528 or other multiple, or is that wrong for this build?
-
Dr.Venom, what fd value are you using? I believe that with the new fd implementation it'll be benefitial to increase fd as much as possible. The wait for vblank is a tight loop that'll eat all cpu cycles so the shorter the time we are in it the more idle cpu cycles there'll be for other stuff. Just in case.
-
EDIT: What do you exactly mean with "the other way around". If I have the driver set to a latency of 48 samples, can I still set the asio_holdoff to 528 or other multiple, or is that wrong for this build?
Sorry about this. It'll vary between drivers a bit but the general rule is basically 800 - asio_holdoff = the amount of samples you want consistently in the buffer. So a setting of 672 means that we try to keep 128 samples in the buffer.
Edit: So a proper setting for a latency of 48 should (with this wonky build) be 800 - 48 * 4 = 608. Which means that we can allow for four missed BASSASIO fetches basically.
-
That only leaves us with the "lowest possible latency test" comparison (as I reported earlier).
When using ddraw with the genesis driver I can get as low as 48 with a holdoff of 528, with zero over-/underruns. When running this setting with d3d, the emulator either produces a continuous stream of underruns (small sample quoted below) and/or crashes. This remains until raising the holdoff to 816. In other words a 6ms "lowest possible audio latency" difference between ddraw and d3d.
I'm not sure how this test will hold up for other drivers though. It's just that if ddraw allows me to go to a holdoff of 528 for the genesis driver, I want to be able to do that with d3d too! ;)
Intealls, could you possibly also run this "lowest possible latency test" to compare d3d and ddraw performance with the genesis driver for your system? I'm curious whether you'll get comparable results. It may provide a last missing link?
Absolutely, and thank you for doing the tests and reporting them, like I said previously I would probably never have attempted it otherwise.
And regarding the lowest possible latency test, I already did it. :) The above genesis runs were with the new fd code + d3d/ddraw, and no over/underruns in any of them. The plot in the 10 minute run shows that the buffer consistently contains about 90 to 140 samples, meaning virtually no latency added from ASIO's side of things.
-
Also, I managed to get kX to accept a 48 buffer size without dropouts by changing the sync method to Kernel/SMP.
Thanks for this tip! I can also achieve even lower latencies with this setting. Unfortunately, it does seem pretty CPU intensive, like you mentioned. CVS1K games like futari15 drop to 90% speed or lower on my 4.6ghz G3258.
Also, are any of you using a lightweight front-end that works well with the ASIO patch? Now that the timings are getting so tight, GameEx is causing some instability that doesn't exhibit itself when Mame is used alone. Using higher latencies helps.
-
I use MaLa, which seems pretty light on resources. It doesn't have all the bells & whistles of FEs like GameEx and HyperSpin, though.
-
Dr.Venom, what fd value are you using? I believe that with the new fd implementation it'll be benefitial to increase fd as much as possible. The wait for vblank is a tight loop that'll eat all cpu cycles so the shorter the time we are in it the more idle cpu cycles there'll be for other stuff. Just in case.
After reading this, I decided to try properly with -mt. Currently, the ASIO patch contains d3d9ex (not sure this affects audio in any way though), the m_speed hack (consistent speed for 1 second before setting m_speed) the new fd code, and the audio generation at the end of the frame update.
I cannot see any adverse effects with -mt and the current combination of patches, at least not for ASIO. I double checked the input response (yes we get next frame response) and sound output delay (doesn't seem to be affected in any way). The speed percentage is a tiny, tiny bit more unstable with using -mt, but my current tests show it has no actual effect whatsoever.
Currently I try to keep about 128 samples in the buffer. An underrun occurs when the buffer is empty. I did 20 minute runs of the following games: fd6: gunforc2, mk2, fd7: neodrift, pbobble, sf2hf, sfa3. The worst case scenario was 1 underrun. I did a couple of 20 min runs with fd8, which all seemed to favor the new d3d code over ddraw as per the below info. This is truly awesome.
game d3d (o/u) ddraw (o/u)
------------------------------
pbobble 0/5 0/20
sf2hf 0/5 1/27
sfa3 3/29 1/61
neodrift 1/46 1/117
Looking at the sample buffer stability, possibly even in favour of d3d!
I agree!
-
Dr.Venom, what fd value are you using? I believe that with the new fd implementation it'll be benefitial to increase fd as much as possible. The wait for vblank is a tight loop that'll eat all cpu cycles so the shorter the time we are in it the more idle cpu cycles there'll be for other stuff. Just in case.
I was using fd2, purely for testing purposes, as I was still under the impression that fd negatively affected the asio latency (as it did with the earlier builds). With the latest release I see this is no longer the case, on the contrary even :)
Edit just one more time:
I've uploaded the build used for these tests to here https://mega.nz/#!jsREGTKT!v0lQ2TUziRnFrOpzEn5VuYo3i5G8ShFKnXNjlTG7i1w (https://mega.nz/#!jsREGTKT!v0lQ2TUziRnFrOpzEn5VuYo3i5G8ShFKnXNjlTG7i1w) , but it's really, really broken and should only be used to check my statements above. Also, with this particular build, asio_holdoff works the other way around, and should be set to 672 with a latency setting of 48. Also I've attached the Octave script used for calculating mean/max etc.
Thanks for posting all of your test results. After testing this release, I can say one thing: truely awesome performance indeed! The Genesis driver now runs with fd8 (!) and a ~96 samples buffer (!!) consistently without any issues in D3D! I've attached a picture with the octave profile*, see: genesis-d3d_fd8-2x48-mt.png
* note that I'm deleting the very first unstable values from the log, to get the scale as small as possible for these comparison purposes.
Even more interesting is that at these settings, when it comes to the "screenswitching" done by Mega Turrican (using super resolution 1280x0), d3d is clearly outperforming ddraw. Apparently ddraw is not as quick doing these x4 and x5 width switches as d3d, resulting in a far less stable soundbuffer at these switching moments. You can see this by comparing the d3d picture with the large spikes at the switching moments in the audio buffer for ddraw, as shown in genesis-ddraw_fd8-2x48-mt.png
Note that I use a trick here to get the game to switch screenmode more often. If you'd like to replicate that:
when the intro runs press fire -> title screen (switch)-> wait for about 10 seconds -> level 1 starts to demo (switch)
-> press fire -> title screen (switch)-> wait for about 10 seconds -> level 2 starts to demo (switch)
-> rinse and repeat, and you'll get level 3 and level 4 demo'd also (enjoy the great Chris Huelsbeck level 3 tune!).
So within a test of 2 minutes you can get it to generate a number of screenswitches. These are exactly the big spikes you're seeing in the ddraw graph genesis-ddraw_fd8-2x48-mt.png. To make this even more convincing just compare it to the graph genesis-ddraw_fd8-2x48-mt_v2.png, where I let the whole intro run (so you only have one screenswitch in the beginning). This also shows in the graph, as there's only one spike in the audio buffer in the beginning, but for the rest it's smooth.
Verdict: d3d clearly outperforms ddraw in this test. Add these to your extensive set of d3d/ddraw comparisons, and (at least to me) it seems clear that D3D is the winner with this latest build. I think Calamity will be happy now :)
I've also attached a run of 1944 using framedelay 8 and the same insanely small soundbuffer. It runs completely without issues, see 1944-d3d_fd8-2x48-mt.png
With regards to using multithreading or not, I can confirm your test results, that there doesn't seem to be any adverse effect from using it. At least when it comes to asio stability. My preference now is to actually keep it on by default. Calamity I guess you may not need to change the multithreading implementation given these test results?
Also, I think now is the time to get a better understanding of how the sound system works, since I think there's intermediary buffering going on, which may or may not be driver-dependent. I find it difficult to believe that the actual pbobble hardware would buffer as many samples as shown in the topmost plot in this post http://forum.arcadecontrols.com/index.php/topic,141869.msg1469093.html#msg1469093 (http://forum.arcadecontrols.com/index.php/topic,141869.msg1469093.html#msg1469093), however actual hardware tests would need to be conducted. I've got a NeoGeo sitting here that I haven't hooked up yet, to use for comparison (though not with pbobble).
I would love to see the real hardware compared to the current implementation and see where we really are in the total latency chain now. Hopefully you come around do doing these tests.
Lastly, could you possibly explain how the current ASIO implementation keeps the audio buffer stable? Does this affect sound quality in any way?
-
Thanks for posting all of your test results. After testing this release, I can say one thing: truely awesome performance indeed! The Genesis driver now runs with fd8 (!) and a ~96 samples buffer (!!) consistently without any issues in D3D! I've attached a picture with the octave profile*, see: genesis-d3d_fd8-2x48-mt.png
* note that I'm deleting the very first unstable values from the log, to get the scale as small as possible for these comparison purposes.
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.
Even more interesting is that at these settings, when it comes to the "screenswitching" done by Mega Turrican (using super resolution 1280x0), d3d is clearly outperforming ddraw. Apparently ddraw is not as quick doing these x4 and x5 width switches as d3d, resulting in a far less stable soundbuffer at these switching moments. You can see this by comparing the d3d picture with the large spikes at the switching moments in the audio buffer for ddraw, as shown in genesis-ddraw_fd8-2x48-mt.png
Note that I use a trick here to get the game to switch screenmode more often. If you'd like to replicate that:
when the intro runs press fire -> title screen (switch)-> wait for about 10 seconds -> level 1 starts to demo (switch)
-> press fire -> title screen (switch)-> wait for about 10 seconds -> level 2 starts to demo (switch)
-> rinse and repeat, and you'll get level 3 and level 4 demo'd also (enjoy the great Chris Huelsbeck level 3 tune!).
Nice trick. :) This is a fabulous game btw. Used to play 1 and 2 on the Amiga.
With regards to using multithreading or not, I can confirm your test results, that there doesn't seem to be any adverse effect from using it. At least when it comes to asio stability. My preference now is to actually keep it on by default. Calamity I guess you may not need to change the multithreading implementation given these test results?
Mine too! The only thing I've noticed is that if using -window, the emulator seems to lock up when moving it around.
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.
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.
When a higher audio latency setting is used, more samples are kept from the get-go, say we discard 800 - 64 * 3 for audio_latency 2. The buffer will also rewind a bit more when getting underruns, to try and prevent them from happening again.
Edit: some clarifications
-
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 (http://forum.arcadecontrols.com/index.php/topic,142143.msg1521066.html#msg1521066)) 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 (http://chrishuelsbeck.bandcamp.com/album/turrican-soundtrack-anthology-vol-1) and vol 2 here (http://chrishuelsbeck.bandcamp.com/album/turrican-soundtrack-anthology-vol-2). 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 :)
-
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?
-
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 (http://forum.arcadecontrols.com/index.php/topic,142143.msg1521066.html#msg1521066)) 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 (http://chrishuelsbeck.bandcamp.com/album/turrican-soundtrack-anthology-vol-1) and vol 2 here (http://chrishuelsbeck.bandcamp.com/album/turrican-soundtrack-anthology-vol-2). 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.
-
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!
-
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
-
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 (http://forum.arcadecontrols.com/index.php/topic,142143.msg1521513.html#msg1521513) 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 (https://mega.nz/#!ykg3jI5b!SO8H3Q9IpLjrYjcxUF4eUIe5Ayhhb7PIpbaYt-74loE)
Edit: added an updated Octave script for visualizing the ASIO log
Edit: r2.1 fixes a patch apply issue
-
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 (http://forum.arcadecontrols.com/index.php/topic,142143.msg1521477.html#msg1521477)). Hopefully this can be ironed out!
-
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?
-
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)?
-
@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).
-
@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 (https://mega.nz/#!6whHAbqI!4ZYisK03Bfieevrj5pOv7-4mNwo9D-NBvAUJc2c98r4) 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.
-
@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 (https://mega.nz/#!6whHAbqI!4ZYisK03Bfieevrj5pOv7-4mNwo9D-NBvAUJc2c98r4) 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 :)
-
@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).
-
@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%.
-
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 (http://forum.arcadecontrols.com/index.php/topic,142143.msg1521513.html#msg1521513) 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 (https://mega.nz/#!ykg3jI5b!SO8H3Q9IpLjrYjcxUF4eUIe5Ayhhb7PIpbaYt-74loE)
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.
-
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.
-
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.
-
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:
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?
-
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.
-
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.
-
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.
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.
-
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 .
-
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.
-
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/speccontent.htm#response%20time)
http://www.tftcentral.co.uk/reviews/content/acer_xg270hu.htm#detailed_response (http://www.tftcentral.co.uk/reviews/content/acer_xg270hu.htm#detailed_response)
-
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...
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
Calamity, could you confirm this in the context of the current framedelay implementation?
Absolutely.
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.
-
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.
-
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?
-
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.
-
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.
-
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?
-
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.
-
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 (http://reboot.pro/topic/2148-news/page-4#entry192685)
-
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
-
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 (http://reboot.pro/topic/2148-news/page-4#entry192685)
That reminds me of the Amiga RAM disk :)
I've recreated the graph using this, but for my setup it doesn't seem to make a material difference.
In regards to variable emulation time. Deathsmiles for instance seems to vary quite a bit, and might make a nice (if difficult) test case.
It seems a difficult case indeed. The graph would suggest lowest speed is (safely) about 300%, allowing for framedelay of 6. Running deathsml with this value keeps it overrunning though. It only becomes somewhat stable when I use fd 2.
-
It seems a difficult case indeed. The graph would suggest lowest speed is (safely) about 300%, allowing for framedelay of 6. Running deathsml with this value keeps it overrunning though. It only becomes somewhat stable when I use fd 2.
Hmm. The speed percentage is updated four times per second. Maybe this isn't accurate enough. Perhaps we need to time each frame.
-
Could you lift the veil a little bit of what possible solution with the scanline number you're thinking of? :)
The idea is, instead of measuring the speed when running full speed, which requires to run the game unthrottled at least once, simply start running the game with fd 0, at normal speed. But because fd is 0, the throttle function won't wait at all and will go directly to the render code. At this point, we read the current scanline. This value will indirectly give us the emulation speed, in scanlines, because we know the value it had when we left from there the last time. Ideally, on a relatively fast machine this value, with fd 0, will correspond to a scanline by the top of the screen. Say we left v-sync at the first scanline, which is #22 (remind first is not zero), and then we're back at scanline #26, this means the frame took 4 full scanlines to emulate. This means, if our vertical total is 262 lines, we could wait until scanline 262-4 = 258 and still don't miss the retrace. Thus we'd use this value as a feedback to go increasing fd internally, until we reach that position. Think the value of fd and the first scanline number when we arrive at the render code are the same concept. Obviously the problem in practice is dealing with the variable emulation speed. If the algorithm tries to squeeze the scanlines to the maximum then as soon as a frame takes an extra scanline to emulate we'll be late. So we'll need to add some sort of security buffer, of a given number of lines (this is what I meant), so we have some tolerance. This won't work anyway for games like deathsmiles with such variations in speed, and this is the situation I don't know how to deal with. A dirty but maybe effective solution would be to allow the current automatic fd value to be shown when pressing f11, and allow adjusting it manually through the ui for the cases where it's required (I'm hating the idea of adding anything to the ui but just suggesting it).
-
This won't work anyway for games like deathsmiles with such variations in speed
If the control loop can be made quick enough, a feasible solution might be to reset it at a missed deadline, to limit the drop to a single frame. Also, I think there's a lot more speed variation in the drivers than one would think. Did a few -nothrottle runs with neodrift/sfa3 and Mega Turrican and they vary quite a bit, as can be seen in the plots below. Of course they all eat a lot less CPU than Deathsmiles do, limiting the actual impact.
-
lol uh, I just tried -nothrottle along with the same settings as before and got ~102000% speed o.O.
-
If the control loop can be made quick enough, a feasible solution might be to reset it at a missed deadline, to limit the drop to a single frame. Also, I think there's a lot more speed variation in the drivers than one would think. Did a few -nothrottle runs with neodrift/sfa3 and Mega Turrican and they vary quite a bit, as can be seen in the plots below. Of course they all eat a lot less CPU than Deathsmiles do, limiting the actual impact.
The problem is how to know for sure when a deadline has been missed. Unfortunately we can't access the internal frame counter through d3d9. I believe it can be done with newer versions of DirectX though. So some heuristics are required.
-
The idea is, instead of measuring the speed when running full speed, which requires to run the game unthrottled at least once, simply start running the game with fd 0, at normal speed. But because fd is 0, the throttle function won't wait at all and will go directly to the render code. At this point, we read the current scanline. This value will indirectly give us the emulation speed, in scanlines, because we know the value it had when we left from there the last time. Ideally, on a relatively fast machine this value, with fd 0, will correspond to a scanline by the top of the screen. Say we left v-sync at the first scanline, which is #22 (remind first is not zero), and then we're back at scanline #26, this means the frame took 4 full scanlines to emulate. This means, if our vertical total is 262 lines, we could wait until scanline 262-4 = 258 and still don't miss the retrace. Thus we'd use this value as a feedback to go increasing fd internally, until we reach that position. Think the value of fd and the first scanline number when we arrive at the render code are the same concept. Obviously the problem in practice is dealing with the variable emulation speed. If the algorithm tries to squeeze the scanlines to the maximum then as soon as a frame takes an extra scanline to emulate we'll be late. So we'll need to add some sort of security buffer, of a given number of lines (this is what I meant), so we have some tolerance. This won't work anyway for games like deathsmiles with such variations in speed, and this is the situation I don't know how to deal with. A dirty but maybe effective solution would be to allow the current automatic fd value to be shown when pressing f11, and allow adjusting it manually through the ui for the cases where it's required (I'm hating the idea of adding anything to the ui but just suggesting it).
It would be interesting to see how well such an approach could work. Of course having things automatic does has its advantage, but as has been mentioned you're always a bit behind the fact, which brings its disadvantages. Personally I'm a bit skeptical as you either have to keep a very safe distance, or you run the risk of skipping frames, which is a no go in my book.
So in some sense it may be giving away some latency reduction (versus a manually optimized setting) for the benefit of ease of use. I guess I'm more of a perfectionist, wanting it to run to the absolute lowest latency. But I understand that there are users, who would gladly trade that in for some more ease of use.
I'm really liking your idea of measuring frame emulation time trough the scanline method. Could a first step possibly be to create some statistics with this, such as single longest frame time, average of 1% longest frame times, average frame time, and given this the amount of framedelay "overruns" and report these on exit? That would be really useful for having an easy way to get better understanding of how this all works out in the various drivers we're testing.
Edit: deleted some possibly incorrect reasoning re the automatic framedelay ;)
-
The problem is how to know for sure when a deadline has been missed.
If a too high framedelay causes the frame emulation to flow over into the next frame, how is that currently handled?
WinUAE used to still flip the frame when missing vblank, as long it was less than one third into the new frame. This may lead to occasional screentearing, but Toni regarded this as being preferable to dismissing the entire frame. (Don't know if it's still working that way in WinUAE). Maybe that could be a useful part of the approach when handling overflows with an automated framedelay algorithm?
-
If the control loop can be made quick enough, a feasible solution might be to reset it at a missed deadline, to limit the drop to a single frame. Also, I think there's a lot more speed variation in the drivers than one would think. Did a few -nothrottle runs with neodrift/sfa3 and Mega Turrican and they vary quite a bit, as can be seen in the plots below. Of course they all eat a lot less CPU than Deathsmiles do, limiting the actual impact.
This is quite enlightening, the speed variations in the drivers are certainly larger than one would think. I also ran mega turrican unthrottled, and besides there being large speed differences, it's great to see how performance sometimes dips slightly below 750%. Displays it very well why I need to run it with a max fd of 7.
Maybe a silly thought, but since this provides such a great insight, would it be an idea to add a little math and an extra colum to the asio log, that displays the maximum frame delay (preferably rounded to real framedelay units) in an additional graph?
-
If the control loop can be made quick enough, a feasible solution might be to reset it at a missed deadline, to limit the drop to a single frame. Also, I think there's a lot more speed variation in the drivers than one would think. Did a few -nothrottle runs with neodrift/sfa3 and Mega Turrican and they vary quite a bit, as can be seen in the plots below. Of course they all eat a lot less CPU than Deathsmiles do, limiting the actual impact.
This is quite enlightening, the speed variations in the drivers are certainly larger than one would think. I also ran mega turrican unthrottled, and besides there being large speed differences, it's great to see how performance sometimes dips slightly below 750%. Displays it very well why I need to run it with a max fd of 7.
Maybe a silly thought, but since this provides such a great insight, would it be an idea to add a little math and an extra colum to the asio log, that displays the maximum frame delay (preferably rounded to real framedelay units) in an additional graph?
Sure, I can add that to the script. When run with -nothrottle, I've changed so that the speed percentage reflects the actual frame render speed (not an average). So when specifying -nothrottle and a value for -seconds_to_run one should get a pretty good idea of what fd value could be considered stable when examining the log.
Edit:
Ok, added. -mt should be disabled. Run the game with -nosyncrefresh -nowaitvsync -nothrottle -seconds_to_run -notriplebuffer. Then simply do s('path to log', 60.0) for genesis for instance. It's saved in RAM now so the log can't be viewed until after emulator exit. I think I got the formula right, but double check it to be sure. You can also use -video none. Note that ASIO output is disabled with -nothrottle.
https://mega.nz/#!a0ZGVASI!AhPJugKmGkRqImH-chiynBGAHJGaQFyh585aPaSnXAs (https://mega.nz/#!a0ZGVASI!AhPJugKmGkRqImH-chiynBGAHJGaQFyh585aPaSnXAs)
Edit again:
Updated the script to output the occurrence of each fd value, minor modification
-
Ok, added. -mt should be disabled. Run the game with -nosyncrefresh -nowaitvsync -nothrottle -seconds_to_run -notriplebuffer. Then simply do s('path to log', 60.0) for genesis for instance. It's saved in RAM now so the log can't be viewed until after emulator exit. I think I got the formula right, but double check it to be sure. You can also use -video none. Note that ASIO output is disabled with -nothrottle.
https://mega.nz/#!a0ZGVASI!AhPJugKmGkRqImH-chiynBGAHJGaQFyh585aPaSnXAs (https://mega.nz/#!a0ZGVASI!AhPJugKmGkRqImH-chiynBGAHJGaQFyh585aPaSnXAs)
Edit again:
Updated the script to output the occurrence of each fd value
Awesome, many thanks for creating this! :) The addition to see the occurence of each fd value in a table is great.
With regards to the formula, I think it needs a small adjustment. Framedelay in gm is set in units of 1/10th of frametime, and is being "off" by 1 unit as Calamity noted. So although the current formula is a good approximation and works for the edge cases (such as frame emulation time getting very small), it will generally give a (too) positive skew to the maximum framedelay values.
I changed the following line is s.m:
fdvals = round((frame_time - (frame_time ./ data(:,1))) / (frame_time / 9) - 0.5);to
fdvals = round((frame_time - (frame_time ./ data(:,1))) / (frame_time / 10) - 1 - 0.5);
The attached graphs shows how this affects the results for a run of deathsml.
I've created a simple script that asks for a driver name and time to benchmark (see attached mame64bench.bat). Just to save a bit of typing everytime. This made me think that it should be possible to extend the script with a call to Octave (CLI?) and have it all fully automated? But for that we would also need to have the driver refresh rate available to the script.
I did notice one particular thing when benching the genesis driver. There is a peculiar speeddrop to about 113% for two frames in the middle of the test when i run a bench for 240 seconds, see attached image. This occurs every time when I run the test, any idea what may be causing this?
I also wondered if there's a specific reason that the benchtest needs to be run with -mt disabled?
@Calamity
Rethinking your approach for automation of fd, that would probably nicely work for the (big) lot of drivers that are able to run at high speed, with the variations only occuring above a certain level. The problem as you noted will be with the deathsml like drivers. What would you think of an approach where if the automated fd value detects to many overruns or "resets", that it logs this with a message to the user to run a benchmark of the driver, possibly like the one that intealls created? It would need a little bit of polishing for end-user usage and robustness, but with this approach we would have the best of both worlds.
Over the years, when hardware get's more and more powerful, the need for applying the manual benchmark will ofcourse fade, and automated fd will gradually take over. I'm getting more enthusiastic about your automation idea :)
-
Edit: r2.1 fixes a patch apply issue
When I apply the asio_163_r2.1.diff I get this error
patching file src/osd/windows/switchres.c
Hunk #1 FAILED at 26.
1 out of 1 hunk FAILED -- saving rejects to file src/osd/windows/switchres.c#
Apparently the patch doesn't expect two empty lines at lines 28+29 in src/osd/windows/switchres.c. Removing one of those lines before applying the patch fixes it.
-
Edit: r2.1 fixes a patch apply issue
When I apply the asio_163_r2.1.diff I get this error
patching file src/osd/windows/switchres.c
Hunk #1 FAILED at 26.
1 out of 1 hunk FAILED -- saving rejects to file src/osd/windows/switchres.c#
Apparently the patch doesn't expect two empty lines at lines 28+29 in src/osd/windows/switchres.c. Removing one of those lines before applying the patch fixes it.
Sigh. I use the --ignore-all-space option when creating the diff, to make it compatible with Visual Studio. I hope this is the option causing problems. I tried applying r2.1 before posting it which worked without issues, but since you're seeing the exact same problem the patch tried to fix, it's probably not fixed.
-
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!
Calamity, are you sure about the frame_delay being off by 1 framedelay unit (1/10th of frametime) of what it's supposed to be, or could it also be that it's off by some other (non framedelay related) constant value?
I'm starting to think it may be the latter, but could use some input from you on this.
-
Hi guys,
Some more tests results.
To summarize the findings: framedelay is not off by 1 framedelay unit, and it is possible to run fast drivers with framedelay 9 without issues.
I found out after testing some more with the benchmark tool, it showed wrong values for maximum framedelay when compared with real runs of gm, and suggested the framedelay "off by 1" notion isn't exactly right.
I managed to overclock my 4790 to 4.7Ghz stable, which made it possible to run genesis at fd8. See attached runs for the genesis driver fd8 with audio latency 1 to 3. They all run without issues. But also see the first two benchmark graphs (intealls div9 and the div10minus1 method), they incorrectly suggest a maximum framedelay of 7. Only after removing the "off by 1" correction in the benchmark formula, it shows the correct max framedelay of 8 for genesis (see benchmark-genesis-div10.png).
This made me think there's something smurfy about the framedelay "off by 1" notion. To confirm this I tested the odyssey2 driver that runs almost 3000% unthrottled and indeed, this runs completely without issues at framedelay 9, see attached graph odyssey2_fd9_48_2.png.
Based upon this the correct benchmark formula (as it stands now) is:
fdvals = round((frame_time - (frame_time ./ data(:,1))) / (frame_time / 10) - 0.5);
See the attached benchmark graph for the odyssey driver, correctly suggesting fd9. (Adding the "off by 1" would wrongly suggest max fd of 8 ).
But given Calamity's finding that there's probably some sort of offset (which now appears to be smaller than a whole framedelay unit), the question becomes how large this offset actually is and what's causing it?
It would suggest that the framedelay waiting loop isn't exactly started at the beginning of a new frame, but a bit (although less than a whole fd unit) later.
Hopefully we can nail this more precisely!
-
Sorry, I'm quite busy these days...
To summarize the findings: framedelay is not off by 1 framedelay unit, and it is possible to run fast drivers with framedelay 9 without issues.
You need to log the first scanline number when you arrive at the d3d render code. That number should approximate v_total * fd /10.
-
Hi intealls,
I've been using the ASIO patch with great pleasure and find it to be pretty solid.
Since this thread is called "pre-alpha", I was wondering if you're looking for further specific improvements, before getting to beta or final stage?
-
Hi intealls,
I've been using the ASIO patch with great pleasure and find it to be pretty solid.
Since this thread is called "pre-alpha", I was wondering if you're looking for further specific improvements, before getting to beta or final stage?
Thanks!
When GM 0.165 gets released, it's going to be bumped to alpha. There's an automatic frequency calibration routine in place now, which will hopefully work well for most ASIO drivers, which eats virtually no CPU. However, it's still possible to input the manually calibrated frequency, which will disable the automatic frequency calibration.
Regarding driver stability (and performance), the more stable the driver is, the easier it gets to find the correct calibration frequency. ASIO4ALL+Realtek seems to (weirdly enough) be the most stable of the ones I've tested, it's slow though (frame_delay needs to be turned down a notch or two). kX is very unstable, but quick (doesn't seem to affect performance with high frame_delay settings). The Xonar driver is placed somewhere in between ASIO4ALL and kX. Everything can be visualized with -asio_log and Octave, so we can find the best card/driver to use. :)
Other than that, a lot of testing has been done for GM with LCDs. With the 0.165 release, I'm going to do a writeup of the correct settings to use (with CRTEmudriver or LCDs).
-
When GM 0.165 gets released, it's going to be bumped to alpha. There's an automatic frequency calibration routine in place now, which will hopefully work well for most ASIO drivers, which eats virtually no CPU. However, it's still possible to input the manually calibrated frequency, which will disable the automatic frequency calibration.
Sounds great, I think that especially novice users will be happy with that.
Regarding driver stability (and performance), the more stable the driver is, the easier it gets to find the correct calibration frequency. ASIO4ALL+Realtek seems to (weirdly enough) be the most stable of the ones I've tested, it's slow though (frame_delay needs to be turned down a notch or two). kX is very unstable, but quick (doesn't seem to affect performance with high frame_delay settings). The Xonar driver is placed somewhere in between ASIO4ALL and kX. Everything can be visualized with -asio_log and Octave, so we can find the best card/driver to use. :)
Yes the difference between the various drivers is interesting. It may be that the ASIO4ALL+Realtek seems most stable because your other two options are on PCI-Express. In my experience using the HPET timer causes unstable results for audio-cards on PCI-Express. On-board soundchips seem much less affected in the same situation (thus making them look relatively stable).
The only solution to that is using the PMTimer (~3.579545 MHz), which can be accessed in W7 by the combination of:
- HPET OFF in bios
- bcdedit /set useplatformclock true
I know your systems don't have the ability to switch off the HPET in BIOS, but if you would ever get the chance to test the Kx and xonar cards/drivers on a system with above settings, it would be interesting to see if you get different (i.e. more stable) results for the PCI-Express cards. But only testing it would confirm it, so I'm interested in the results also :)
Other than that, a lot of testing has been done for GM with LCDs. With the 0.165 release, I'm going to do a writeup of the correct settings to use (with CRTEmudriver or LCDs).
Great, looking forward to that!
-
Bump to 0.165! Check the first post for info.
-
Will be grabbing this as soon as I get spare time aware from restoring another cab. The auto calibration sounds great! Thanks intealls!! :applaud:
-
Thanks for the latest update! Seems great so far. Does your bench show that you can use frame_delay 8 reliably with any games? Everything I've checked so far gives me a figure above 95%. For example, I can run Terra Cresta at 2925%, but the bench indicates I should use frame_delay 7. I'm just wondering what other people are seeing.
-
Thanks for the latest update! Seems great so far. Does your bench show that you can use frame_delay 8 reliably with any games? Everything I've checked so far gives me a figure above 95%. For example, I can run Terra Cresta at 2925%, but the bench indicates I should use frame_delay 7. I'm just wondering what other people are seeing.
The benchmark simply measures frame times and reports the occurrence of observed frame times as percentages of frame delay values. The benchmark is also likely to be driver dependent, of the ones I've tested, the kX driver seems to be the fastest. Try doing a bench with -sound none, even though I can't really recommend this. One should also run the bench at least twice, to rule out issues with the PC.
When testing, I've found that the frame delay value the benchmark reports will enable you to run the benchmarked game with a minimal amount/no frameskips (which in turn will not make the buffer over/underrun), however, you should be able to get pacman to report 8 (it runs at several thousand percent). Have you successfully been able to run terracre at fd 8 for a longer period of time (say 20-30 minutes) without over/underrun issues?
-
Thanks for verifying. This is what I get with Pacman.
SwitchRes: [pacman] (1) vertical (224x288@60.61)->(2560x288@51.14)
Frame delay/percentage: 0/0.06% 8/99.94%
Average speed: 16474.14% (180 seconds)
At frame_delay 8 with no ini files present, I got "ASIO: Overrun/underrun: 683/130" over 42 minutes.
So I assume the bench is accurate. This is with the kx driver with the default sync and 96 samples. I tried different values up to 384 but the bench result was the same.
This machine is heavily overclocked so I probably have some issues running fd8 reliably. Very nice to have some additional information to verify this rather than unknowingly running with unstable settings. I'll work on it sometime. Thanks again!
-
At frame_delay 8 with no ini files present, I got "ASIO: Overrun/underrun: 683/130" over 42 minutes.
This was with terracre, right? On my G3258 clocked at 4 GHz with kX (96 sample size, default sync) I get ASIO: Overrun/underrun: 2/1 after a 1500 second pacman run. It might be possible to get rid of the over/underruns completely by setting -nosleep and -priority 1.
Also as a reminder, for proper ASIO operation multithreading must be enabled.
-
Thanks. This was with Pacman. setting sleep to 0 and priority 1 is my normal config, but these options didn't change anything. I still get a 99.99% fd8 value from -bench along with overruns/underruns. I tried a variety of things this morning and nothing really changed the situation.
-Tried each HPET/bcdedit configuration for timers.
-Reset BIOS to default settings to eliminate overclock.
-Tried high audio latencies and various Kx settings (Default, KRNL/SMP, etc...)
-Tried both regular and super resolution configs in VMMWAKER
-Removed secondary monitor
-Tried both d3d and ddraw
-adjusted a variety of overclocking settings and disabled some CPU features like speedstep and others.
That's about it, I think. I assume this is just the limit of what my current hardware configuration can do with stability at frame_delay 8. However, I can run most games at frame_delay 7 with very low audio latency, so I'm quite happy regardless. When I get a chance to rebuild my secondary machine that uses older hardware, I'll see if it behaves the same.
-
Thanks for the detailed tests!
Very strange. What kX driver version and card are you using?
Would you mind giving ASIO4ALL a go (preferrably with official Realtek drivers) and see if it behaves the same?
-
Hi vicosku,
Thanks for verifying. This is what I get with Pacman.
SwitchRes: [pacman] (1) vertical (224x288@60.61)->(2560x288@51.14)
Frame delay/percentage: 0/0.06% 8/99.94%
Average speed: 16474.14% (180 seconds)
At frame_delay 8 with no ini files present, I got "ASIO: Overrun/underrun: 683/130" over 42 minutes.
You can't use that game for testing purposes as it's probably activating triplebuffer (check your log). With triplebuffer enabled no proper timing based on vsync is possible. Actually syncrefresh is indispensable for frame_delay to work at all. GM can only use either triplebuffer or syncrefresh, not both, that's the problem. You don't need to force syncrefresh manually, however, it'll be enabled automatically by GM, except in cases like this where the target refresh can't be achieved (60.61 vs 51.14). So what you have to do is to run this game at its native orientation.
-
Actually syncrefresh is indispensable for frame_delay to work at all.
Thanks for pointing this out, I was under the false impression frame_delay was active also when triple buffer was active. I should also add to the first post that it's very much recommended to let SwitchRes handle all the settings (which is why multithreading needs to be enabled (triple buffer)). Pretty much all of my recent testing is done with SwitchRes handling all settings.
Another game that runs as fast as pacman is rallyx, which might be better to use as a 'does the rig work properly' test, since it's horizontally oriented.
-
The automatic frequency calibration seems to work just as well as manually inputting a value, so that's cool :).
The dialogue box for the benchmark disappears immediately just like the batool64 cal freq one used to. "Press any key to exit" would be nice on this one too.
I managed to print screen the benchmark dialog box before it disappeared, and I basically got a similar result to the one in the first post, but using SFIII: 3rd Strike, so something like:
Frame delay/percentage: 0/0.31% 7/3.51% 8/96.18%
I was using fd_8 before, but tried 7 in light of this result. Thing is, there wasn't much difference in buffer overruns and underruns. For a 1 minute run of SFIII:3rd Strike I got 2/4 with 96 samples and fd_8, and 0/3 with fd_7. At 196 samples, both values of fd resulted in 0/2. At 288 samples, both values got 0/1. To me, that's a negligible difference, especially because I intend to use 288 samples at which there was literally no difference in my brief testing. Should I carry on using fd_8 in this case, or are the bench results indicating something important (other than the best value for audio), like video framerate stability?
-
The automatic frequency calibration seems to work just as well as manually inputting a value, so that's cool :).
The dialogue box for the benchmark disappears immediately just like the batool64 cal freq one used to. "Press any key to exit" would be nice on this one too.
I managed to print screen the benchmark dialog box before it disappeared, and I basically got a similar result to the one in the first post, but using SFIII: 3rd Strike, so something like:
Frame delay/percentage: 0/0.31% 7/3.51% 8/96.18%
I was using fd_8 before, but tried 7 in light of this result. Thing is, there wasn't much difference in buffer overruns and underruns. For a 1 minute run of SFIII:3rd Strike I got 2/4 with 96 samples and fd_8, and 0/3 with fd_7. At 196 samples, both values of fd resulted in 0/2. At 288 samples, both values got 0/1. To me, that's a negligible difference, especially because I intend to use 288 samples at which there was literally no difference in my brief testing. Should I carry on using fd_8 in this case, or are the bench results indicating something important (other than the best value for audio), like video framerate stability?
What monitor configuration are you using now? As Calamity pointed out a few posts up, if you're not using syncrefresh (check the log), frame_delay isn't active.
Sfiii3 exhibits varying speeds at in-game transitions (fight->ranking screen etc), and you should probably get worse performance than you're getting.
On my i7-6700k (4.3GHz) I get
Frame delay/percentage: 0/0.13% 2/0.01% 4/0.07% 5/0.07% 6/0.34% 7/12.75% 8/86.65%
With sfiii3. I get similar performance with my G3258 at 4GHz. Also, you should start using cmd to start GM. That way the results won't disappear.
-
Log says:
SwitchRes: Setting option -syncrefresh
In mame.ini:
syncrefresh 1
-
Log says:
SwitchRes: Setting option -syncrefresh
In mame.ini:
syncrefresh 1
Ok, I can't explain this. Would you mind doing a 10 minute run with -asio_log set and upload the log somewhere? All of my testing with sfiii3 has shown that the speed will drop at in-game transitions, leading to underruns. I've attached what a run on my G3258 looks like.
Edit: What CPU are you using btw?
-
Ok, I just played arcade mode for 10 minutes (lots of transitions) with fd_8 and 288 samples and got 0/25. I've attached the asio log and the -v log.
I have an i5-3570k@4.2GHz.
-
Ok, I just played arcade mode for 10 minutes (lots of transitions) with fd_8 and 288 samples and got 0/25. I've attached the asio log and the -v log.
I have an i5-3570k@4.2GHz.
Thanks alot for this. Your log shows the same behavior, if I were to try and explain the minor performance difference between fd8 and fd7, I'd say that the majority of underruns are caused by the transitions, the speeds in between transitions are probably fd8+.
-
Ah ok. So do you think it would be fine for me to use fd_8 then?
-
Ah ok. So do you think it would be fine for me to use fd_8 then?
For this particular game, if you can live with a few underruns at in-game transitions, sure. :)
sfiii3 is tricky, to get rid of the underruns at in-game transitions, you'd pretty much have to run the game at fd1.
-
Ya, that's totally acceptable. Thanks :)
-
Hi intealls,
Thanks for the update. I've been doing a little testing and overall it works great.
Three minor issues:
There seems to be an issue with the -bench time. The seconds to run is not set in seconds but in 1/10ths of seconds? So if I use -bench 60, it will only run for 6 seconds. Doing a -bench 600 will run for about 60 seconds.
For games that have writeconfig set to "1" in the ini, using the -bench option will overwrite certain settings, which makes it a hassle to start the game next time. Could you possibly add "-nowriteconfig" when the -bench option is used? That way it will not overwrite settings.
With regards to the framedelay benchmark, it's very nice to have it in there. Coming back to an old issue, for my setup most benchmark results seem to be a bit on the conservative side though. I guess this is because you're using 9 bins, while groovymame framedelay is set in 1/10ths of frametime. Theoretically you should be using 10bins for the calculation.
I guess you're still using 9 bins, because of Calamity's findings of not using framedelay 9? Calamity's findings may be machine and/or video card specific though. (I've also shown in an earlier post that fd9 is possible without issues.)
IMO, I'd rather have the benchmark results show accurate information, based on the correct math, instead of an artifical curtailing of the results. That way the user can decide what value he'd like to use based on the true bin results. I'd love to hear your take on this.
On my i7-6700k (4.3GHz) I get
That's a pretty decent specced cpu :) Out of interest, what mainboard are you using with it?
Thanks again for your continued work on gmasio, great stuff.
-
There seems to be an issue with the -bench time. The seconds to run is not set in seconds but in 1/10ths of seconds? So if I use -bench 60, it will only run for 6 seconds. Doing a -bench 600 will run for about 60 seconds.
Very strange, it works properly on my main rig and GM rig. Does it exhibit the same behavior with -seconds_to_run?
For games that have writeconfig set to "1" in the ini, using the -bench option will overwrite certain settings, which makes it a hassle to start the game next time. Could you possibly add "-nowriteconfig" when the -bench option is used? That way it will not overwrite settings.
Sure, will add it to the next update.
With regards to the framedelay benchmark, it's very nice to have it in there. Coming back to an old issue, for my setup most benchmark results seem to be a bit on the conservative side though. I guess this is because you're using 9 bins, while groovymame framedelay is set in 1/10ths of frametime. Theoretically you should be using 10bins for the calculation.
I guess you're still using 9 bins, because of Calamity's findings of not using framedelay 9? Calamity's findings may be machine and/or video card specific though. (I've also shown in an earlier post that fd9 is possible without issues.)
IMO, I'd rather have the benchmark results show accurate information, based on the correct math, instead of an artifical curtailing of the results. That way the user can decide what value he'd like to use based on the true bin results. I'd love to hear your take on this.
Yes, it's based on Calamity's findings. I've noticed that my GM rig (G3258 @ 4GHz) can run neogeo games at fd8 without issues, even though the benchmark tells me the maximum setting should be 7. I also seem to be able to run nrallyx at fd9 without issues. But I really need to understand every aspect of frame delay before altering it.
The formula used is a simplified version of this one (from a previous post of yours)
(frame_time - (frame_time ./ data(:,1))) / (frame_time / 10) - 1 - 0.5)
That's a pretty decent specced cpu :) Out of interest, what mainboard are you using with it?
ASUS Z170-A. It sure is nice to have a fast rig again. :) Compilation time is really reduced compared to my i5-2500k.
-
Very strange, it works properly on my main rig and GM rig. Does it exhibit the same behavior with -seconds_to_run?
The -seconds_to_run works properly, so with "-seconds_to_run 60" it takes 60 seconds. Whereas with -bench 60 it takes about 6 seconds.
Sure, will add it to the next update.
Thanks.
IMO, I'd rather have the benchmark results show accurate information, based on the correct math, instead of an artifical curtailing of the results. That way the user can decide what value he'd like to use based on the true bin results. I'd love to hear your take on this.
Yes, it's based on Calamity's findings. I've noticed that my GM rig (G3258 @ 4GHz) can run neogeo games at fd8 without issues, even though the benchmark tells me the maximum setting should be 7. I also seem to be able to run nrallyx at fd9 without issues. But I really need to understand every aspect of frame delay before altering it.
I don't think I'm telling you anything new here, but for the sake of understanding:
From what I understand framedelay does nothing else than taking the driver's theoretical frametime (based on the screen refresh rate), divide it by 10, thus making one framedelay unit 1/10th of frametime. The user set framedelay value is multiplied by this unit time, which is then put in the framedelay wait function.
Theoretically this wait function should be started right at the start of the screens' vertical sync, such that there's a whole frame of time (10 framedelay units) before next vblank comes up. That way for example a framedelay value of 9 would wait 9/10th of frametime, and then leave 1/10th of frametime for emulation before vblank is triggered again.
Contemplating what I just wrote, I think we have the following unknowns:
1. Is the framedelay wait function currently started as soon as vsync is reached? I'm not sure whether in the current code it is.
2. Even if it's codewise intented to start as soon as vsync is reached, does it really start at vsync in practice?
I guess the video driver and/or the video card play a role in whether or not this happens. The "for some cards it will for some it won't" may apply here.
But this should be very much possible as I understood from Calamity that the rastertime function has a precision of less than 1 rasterline. (Which could even further improve with Calamity's upcoming support for newer cards.)
That's a pretty decent specced cpu :) Out of interest, what mainboard are you using with it?
ASUS Z170-A. It sure is nice to have a fast rig again. :) Compilation time is really reduced compared to my i5-2500k.
I can imagine, you can never have enough raw horsepower :)
-
The -seconds_to_run works properly, so with "-seconds_to_run 60" it takes 60 seconds. Whereas with -bench 60 it takes about 6 seconds.
The -bench functionality uses the standard MAME stuff, so nothing's been changed there. Also, does the log actually output that the game was running for 6 seconds? The bench time specified is emulated time, not actual time.
I guess the video driver and/or the video card play a role in whether or not this happens. The "for some cards it will for some it won't" may apply here.
Yeah, this is pretty much the part that needs to be understood.
The throttling part can be found in update_throttle, emu/video.c.
if (m_framedelay != 0 && m_framedelay < 10 && m_syncrefresh && mode->hactive)
target_ticks = m_throttle_last_ticks + HZ_TO_ATTOSECONDS(mode->vfreq / mode->result.v_scale ) / attoseconds_per_tick * m_framedelay / 10;
Edit:
Added some minor functionality to see what scanline we're actually ending up at when entering end_frame(), as per a previous tip from Calamity. Tested on nrallyx with CRT Emudriver.
With fd9: entered end_frame at scanline 0, very seldomly we enter at scanline ~250
With fd8: entered end_frame at scanline 228 pretty consistently
This means that Calamity is correct, and fd9 should not be used, since the vblank is missed and the update will be delayed one frame.
This means that a usable benchmark would amount to
(frame_time - (frame_time ./ data(:,1))) / (frame_time / 10) - 0.5)
With fd values 8 and 9 added together.
Edit again:
Further testing has shown that the implementation in place is correct. Frame delay is in practice off by 1 unit (at least with CRT Emudriver and the new fd code).
At fd8, mslug2t intermittently shows that we enter end_frame too late, which is reported by the benchmark in the current patch (which reports a maximum fd of 7, Frame delay/percentage: 0/0.04% 7/18.95% 8/81.02%).
At fd8:
entered end_frame at scanline 254
entered end_frame at scanline 0
entered end_frame at scanline 253
entered end_frame at scanline 0
entered end_frame at scanline 254
At fd7:
entered end_frame at scanline 221
entered end_frame at scanline 222
entered end_frame at scanline 220
entered end_frame at scanline 221
entered end_frame at scanline 219
entered end_frame at scanline 231
entered end_frame at scanline 235
entered end_frame at scanline 236
etc
-
Very strange. What kX driver version and card are you using?
Would you mind giving ASIO4ALL a go (preferrably with official Realtek drivers) and see if it behaves the same?
Notifications for this thread rarely reach me somehow. Looks like I missed a lot! Anyway, this morning I uninstalled kX (Forgot to note the version) and installed the latest Realtek drivers and ASIO4ALL. I left it at the default 512 setting. Nothing changed, and the fd_8 bench still claims 99.9%, and I still get lots of overruns in Pacman. Note that other than I am now running with my usual mame.ini that includes -orientation rotate, so the refresh should be correct.
I've noticed that my GM rig (G3258 @ 4GHz) can run neogeo games at fd8 without issues, even though the benchmark tells me the maximum setting should be 7.
I have my G3258 clocked at 4.6GHz and last I checked, I can't run Neo Geo games at FD8 without noticeable sound issues despite the high speed. Sometimes I'll try to simplify my setup and reduce the number of variables involved to see if I can improve things.
I've added my hardware config to my signature for reference in these discussions from now on. It might be helpful if everyone does the same so we don't have to keep repeating it. I'm sure a lot of people would rather copy Dr. Venom's config than mine, for instance.
-
Great, thanks for investigating further.
As a premature conclusion it seems the framedelay throttle function is started with an unknown delay?
A few quick questions. Could you for both nrallyx and mslug2t check what the results are for framedelay 0? That would complete the picture. If you can share the patch, I will run the exact same tests as you did and report back with them.
And what is considered to be end_frame() in the mame context?
-
I've noticed that my GM rig (G3258 @ 4GHz) can run neogeo games at fd8 without issues, even though the benchmark tells me the maximum setting should be 7.
I have my G3258 clocked at 4.6GHz and last I checked, I can't run Neo Geo games at FD8 without noticeable sound issues despite the high speed. Sometimes I'll try to simplify my setup and reduce the number of variables involved to see if I can improve things.
It could be that at 4.6Ghz the CPU may be getting too hot under load, causing it to throttle the speed when this happens. (I had that happen too with an old rig of mine). You should consider this when choosing a reliable overclock level, as it could well be the cause of the problem you're describing.
My advice would be to test your system with some stresstesting tool, like aida64, and see how it performs under full load. How hot the cpu gets and whether or not it gets autothrottled under full load.
-
Thanks, I'll verify since it's been months since I stress-tested and stabilized this overclock, but I'm confident that heat's not an issue. The results are the same with PacMan at stock 3.2 Ghz with an Arctic Cooling Freezer i11. I believe the highest I've taken this thing is around 66C while trying to hit 5Ghz. No stability issues with it at 4.6Ghz either.
-
I have my G3258 clocked at 4.6GHz and last I checked, I can't run Neo Geo games at FD8 without noticeable sound issues despite the high speed. Sometimes I'll try to simplify my setup and reduce the number of variables involved to see if I can improve things.
Like Calamity pointed out, pacman isn't the best game for testing. Try nrallyx (or rallyx), if those won't work properly with a clean config (-mt -nosleep -priority 1 set), the issue is most likely specific to your PC. Also, for neogeo, how many under/overruns are you getting and how long are you testing?
And what is considered to be end_frame() in the mame context?
I'll need to do some more tests (also take what a say with a grain of salt the next few days, I'm running a fever), but currently on my GM rig it looks like we hit the render code about 7% too late (thus fd8 is actually fd8.7). It's probably worse on lower end rigs (gonna have to verify this). end_frame is in osd/modules/render/drawd3d.c.
I've added my hardware config to my signature for reference in these discussions from now on. It might be helpful if everyone does the same so we don't have to keep repeating it. I'm sure a lot of people would rather copy Dr. Venom's config than mine, for instance.
Good idea, will do the same.
-
I'll need to do some more tests (also take what a say with a grain of salt the next few days, I'm running a fever), but currently on my GM rig it looks like we hit the render code about 7% too late (thus fd8 is actually fd8.7). It's probably worse on lower end rigs (gonna have to verify this). end_frame is in osd/modules/render/drawd3d.c.
Ok, good to know. If there's anything you would want me to test just let me know. Take care with the fever.
@ Vicosku
I get the impression you're trying to optimize too many variable at the same time. We're willing to help, but to prevent us to shoot in the dark, we would need to take it step by step, until the issue is located.
Given the issues you're experiencing, I would suggest to start out with testing and confirming that the basics work and move up from there.
So taking intealls suggestion and adding a bit, I would suggest to do the following:
1. First test *regular* groovymame, so *no* asio and use a framedelay of max 2, try nrallyx with a clean config (-mt -nosleep -priority 1 set). Are you able to run this game for 5 minutes with no or *very little* audio buffer over-/or underruns? Please show log reports.
If not, then there is definitely something in your setup that you need to find.
If you are able to run it without issues then we move on to step 2.
2. Use -regular- GM again, still no asio, but this time start raising the framedelay value step by step. To what level can you raise framedelay while still having zero or very little audio over-/underruns?
If you are able to have zero or very little over/-underruns at fd7 then create step 3 and 4 by reiterating over step 1 and 2, but now having ASIO enabled.
If you run through these steps 1 to 4 as described then you have a very high chance of being able to locate the issue(s) and work towards the solution. Possibly we can help further, but for that it's best if you would report back on above steps with the log results.
/* A short sidetrack:
What I find disturbing is that my Windows 7 setup has been downloading a few gigabytes of Windows 10 update in the background, without my explicit consent! (Check your C drive for the folder $Windows.~BT, and see if you're infected also.) These are the kind of things that can easily "mysteriously" cause intermittent issues in our GM setups. I mean common, WHY is it downloading so many gigabytes, when I haven't even approved of wanting W10 on this machine? This kind of Microsoft ---That which is odiferous and causeth plants to grow--- is really pissing me off.
To make it worse, in Windows 10 you cannot even disable or schedule when regular Windows updates come in anymore. Sigh.
*/
-
Did some more tests.
SwitchRes: Modeline "2560x240_60 15.66KHz 60.00Hz" 54.62 2560 2720 2976 3488 240 246 249 261 -hsync -vsync
barricad (runs at ~32000%)
fd 1: 46 (17.6%)
fd 2: 72 (27.6%)
fd 3: 98 (37.6%)
fd 4: 125 (47.9%)
fd 5: 152 (58.2%)
fd 6: 178 (68.2%)
fd 7: 203 (77.8%)
fd 8: 229 (87.7%)
fd 9: 0 (vblank)
Since barricad runs so fast, we can pretty much disregard the emulation time, and assume the delay is caused by something else.
Also, after reading up on the D3DRASTER_STATUS struct, it seems that it sets the scanline number to 0 when in vblank, so when I thought we missed vblank, we didn't. We're still 7-8% late though, so this needs to be taken into consideration (which it is by the current benchmark, with the obvious 2-3% margin).
There's also tearing to consider. As Calamity has pointed out, even if we manage to hit the present code in time, there's no guarantee that the graphics card is fast enough to scale and show the frame without tearing.
Also, for the scanline logging thing, locate and modify the existing to this in src/osd/modules/render/drawd3d.c (around line 800)
int first_enter = 1;
static int prev_scanline = 0;
// sync to VBLANK
if (window().machine().options().frame_delay() != 0 &&
((video_config.triplebuf && window().fullscreen()) || video_config.waitvsync || video_config.syncrefresh))
{
D3DRASTER_STATUS raster_status;
memset (&raster_status, 0, sizeof(D3DRASTER_STATUS));
while (!raster_status.InVBlank)
{
if ((*d3dintf->device.get_raster_status)(m_device, &raster_status) != D3D_OK)
break;
if (first_enter && prev_scanline != raster_status.ScanLine) {
osd_printf_verbose("entered end_frame at scanline %d, in vblank? %s\n", raster_status.ScanLine, raster_status.InVBlank ? "y" : "n");
first_enter = 0;
prev_scanline = raster_status.ScanLine;
}
if (raster_status.ScanLine >= last_scanline)
break;
}
}
-
@ Vicosku
I get the impression you're trying to optimize too many variable at the same time. We're willing to help, but to prevent us to shoot in the dark, we would need to take it step by step, until the issue is located.
Thanks for the guidance, and sorry for the low effort posts. Though I have more to try, here is where I am so far.
I made a new directory for stock GM .165 and generated a new mame.ini. I only changed 3 values to disable game info and nag screens. rallynx was launched with -mt -nosleep -priority 1 as you suggested. I only tested frame_delay 2 and 8 though, both for 30 minutes. Both tries no overruns or under-runs. I then reduced the audio latency to 1.0 and got 3 overruns and no underruns with fd8.
I then tried GMASIO in the same directory with the same settings. I first tried ASIO4ALL+Realtek with the default 512 setting and got 0 overruns and 5 under-runs with frame_delay 8.
I switched back to kX/Audigy RX (v 3551 this time. I was using 3552 before) and got similar results with 512 samples and default sync (0/3).
I set the slider to the next sample size setting (384) and ended up with 5211/0 overruns. These are audible during gameplay and quite obvious. Changing the sync method in the kX driver helps somewhat, but not enough. Perhaps this is the best I can achieve with ASIO and Frame_Delay 8 with my hardware and drivers.
-
Did some more tests.
Thanks for the tests and code, I hope to do some testing either today or tommorow and report back with the results.
@vicosku
Perhaps this is the best I can achieve with ASIO and Frame_Delay 8 with my hardware and drivers
Thanks for reporting back with the logs. It's really good to see that you're having fine performance with default GM, fd2 + fd8, audio buffer 1, and also when using ASIO with the 512 buffer setting at fd8. This implies that at the core there's nothing wrong with your PC.
It could indeed be that this is the best you can achieve, but before we throw in the towel let's try a few more things. There are some non-intuitive things going on with the buffer sizes (as in: buffer sizes may have some strange correlation to stability) and I'd like to verify this first, plus some other stuff. Some may seem a bit silly, but we need to run through them.
Forget about the Audigy and the Kx driver for the moment. First let's see if we can improve the Realtek+Asio4All combination. Could you please do the following:
1. What version of ASIO4ALL are you using, do you have the latest version 2.12 (from 7 oct 2014) running?
2. Is the rate for your Realtek playback device configured at 16-bit 48000Hz (the windows default is different from this) and does it have the "allow exclusive mode" ticked? (It's in the Windows audio panel advanced options).
3. Run the exact same test for ASIO4ALL+Realtek at fd8, but instead of the 512 buffer size, use 96. Please report back with the log.
4. Hover your mouse over the asio4all icon in the system tray when you have mame running (pause+alt-tab). Does it show 96 samples or some other value in the mouse over pop-up?
5. Please post a picture of your asio4all configuration panel, with the advanced tab opened (it shows a menu called latency compensation with some options).
6. Could you run intealls latest batool for the realtek audio output (it will be unit 0 or 1 please check). What value does it report?
-
Edit: please use barricad instead, it runs 2x-3x the speed of nrallyx.
Thank you for the tests, this is exactly how they should be done.
I set the slider to the next sample size setting (384) and ended up with 5211/0 overruns. These are audible during gameplay and quite obvious. Changing the sync method in the kX driver helps somewhat, but not enough. Perhaps this is the best I can achieve with ASIO and Frame_Delay 8 with my hardware and drivers.
Were you able to get this result repeatedly? Otherwise, it might be that the automatic frequency calibration routine has slipped. I've seen it once or twice, and it's very difficult to reproduce, but I've added new functionality which will hopefully make this issue go away forever (next release).
Would you mind doing another run with kX latency 96 and default sync (and nrallyx fd8 with only -mt -nosleep -priority 1)? Since we have so similar GM rigs it should be possible for me to test here as well. With fd8 you can probably expect a few over/underruns (so 0/5 for a 30 minute run is OK for that buffer size), but certainly not in the thousands. A 30 minute fd8 nrallyx run on my GM rig (with kX 96/default sync) gave me 15/1 with audio_latency 1 (for this build I also did a LOT of printouts to the console, which undoubtedly has influenced the results).
Also, ASIO4ALL with the official Realtek driver appears to be just as fast as kX on my GM rig so you should be able to use that as well, I've actually noticed that it is MUCH more stable than kX, indicating a link with Dr.Venoms FreqTest DX tests. A 30 minute run of nrallyx (fd8) with ASIO4ALL (96 buf, official Realtek driver) yielded 0/0 (log attached).
It would be great if you could do two 15 minute runs of nrallyx (fd8 -mt -nosleep -priority 1) with ASIO4ALL 96 buffer size, and kX (default sync) 96 buffer size, that way I can reproduce the tests easily and we know if the driver's to blame.
-
Thank you both. I've only had time to run a couple of tests with nrallyx and ASIO4ALL+realtek. I'll try more of your suggestions soon. A setting of 96 with default audio latency (2.0) resulted in 1250/79. A setting of 384 resulted in 1682/84.
It really seems like the -bench result I get for fd8 is correct, whatever the reason.
-
It really seems like the -bench result I get for fd8 is correct, whatever the reason.
Thanks Vicosku for reporting back, I think we'll soon be closer to a solution or at least have a satisfactory answer to the issue.
I'm going a bit over the top here, but just to keep things organized:
I've added one item to the list, given the new point discussed with intealls below regarding framedelay possibly being more late. I also added intealls question regarding the test with the kx driver. That way we keep things organised and cross them off the list step by step (intealls, if I forget something please add to the list :) )
Let's keep doing this step by step, as it may provide a good test case in general, benefitting other/future users also.
1. What version of ASIO4ALL are you using, do you have the latest version 2.12 (from 7 oct 2014) running?
2. Is the rate for your Realtek playback device configured at 16-bit 48000Hz (the windows default is different from this) and does it have the "allow exclusive mode" ticked? (It's in the Windows audio panel advanced options).
3a. Run the exact same test for ASIO4ALL+Realtek at fd8, but instead of the 512 buffer size, use 96. Please report back with the log.
3b. Run the exact same test for Kx driver + audigy at fd8, buffer size 96. Please report back with the log.
3c. Run the exact same test for ASIO4ALL+Realtek at fd7, buffer size 96. Please report back with the log.
4. Hover your mouse over the asio4all icon in the system tray when you have mame running (pause+alt-tab). Does it show 96 samples or some other value in the mouse over pop-up?
5. Please post a picture of your asio4all configuration panel, with the advanced tab opened (it shows a menu called latency compensation with some options).
6. Could you run intealls latest batool for the realtek audio output (it will be unit 0 or 1 please check). What value does it report?
@ intealls
What does it mean that sample rate and compensated are the same in the log, is this correct?
sample rate 48000.00, compensated sample rate 48000.000000,
I have a wild hunch of what could be going on with vicosku's results, given your earlier findings (quoted below). It could be that in vicosku's setup the delay in framedelay is more than 7%, meaning that his fd8 is not comparable to "our" fd8...
His delay could for example be 10%+, such that fd8, is not fd8 or fd 8.7, but actually runs effectively towards fd9?
I guess to test this we would need to see what scanline is returned in his setup versus your setup (because both setups are so similar). Or verify whether vicosku can run the low buffer settings at fd7 (which would then effectively be fd8 ; ) ).
but currently on my GM rig it looks like we hit the render code about 7% too late (thus fd8 is actually fd8.7). It's probably worse on lower end rigs (gonna have to verify this). end_frame is in osd/modules/render/drawd3d.c.
-
What does it mean that sample rate and compensated are the same in the log, is this correct?
sample rate 48000.00, compensated sample rate 48000.000000,
It's correct, it indicates that the automatic frequency calibration routine is in use instead of the manually input frequency, should probably clarify this for the next release.
meaning that his fd8 is not comparable to "our" fd8...
If it turns out the ASIO driver isn't to blame, this could be a possible explanation, but needs to be investigated further.
Thank you both. I've only had time to run a couple of tests with nrallyx and ASIO4ALL+realtek. I'll try more of your suggestions soon. A setting of 96 with default audio latency (2.0) resulted in 1250/79. A setting of 384 resulted in 1682/84.
There is a clear tendency to overrun. Please try the kX driver as well, and could you also possibly input a manual calibration frequency? Just to rule out that it's not the automatic frequency calibration routine causing it.
For reference, I'm using the Realtek driver from here: http://download.gigabyte.eu/FileList/Driver/mb_driver_audio_realtek_w10.zip (http://download.gigabyte.eu/FileList/Driver/mb_driver_audio_realtek_w10.zip). It may or may not work on your setup (your mainboard features the exact same codec as mine, ALC887). Also, it works fine with W7 even though Gigabyte specifies it for W10.
My ASIO4ALL is setup according to the attachment (also 16 bit/48000Hz). Also, platformclock is set to false (bcdedit /set useplatformclock false), and my BIOS lacks a HPET on/off setting. So I presume it's on. Other than that I'm using a fairly standard super resolution setup (2308 and 2560). Noticed that you had added a few modes in your config.
-
What does it mean that sample rate and compensated are the same in the log, is this correct?
sample rate 48000.00, compensated sample rate 48000.000000,
It's correct, it indicates that the automatic frequency calibration routine is in use instead of the manually input frequency, should probably clarify this for the next release.
OK, good to know.
Not related to vicosku's issue but just out of interest. I read on the un4seen site about the 16 point sinc interpolator the following:
http://www.bass.radio42.com/help/html/939037c4-b2c1-2c07-c7db-e009f2d941b5.htm (http://www.bass.radio42.com/help/html/939037c4-b2c1-2c07-c7db-e009f2d941b5.htm)
For optimal quality and performance, it is best to set the device to the sample rate you want via BASS_ASIO_SetRate(Double), but that's not always possible. Which is where this function and resampling comes into play. 16 point sinc interpolation is used, giving a good blend of sound quality and performance. It is also SSE2 and 3DNow optimized for an extra boost with supporting CPUs.
When a channel's sample rate is the same as the device rate, resampling is bypassed, so there's no unnecessary performance hit.
And wondered in what (if any) cases the sinc interpolator is used with GMASIO?
Also I understood that a sinc resampler in general would benefit the sound reproduction quality, when resampling a lower rated source (such as from an emulated console) to the PC's 48Khz. Would it as such possibly benefit to have it always on?
-
And wondered in what (if any) cases the sinc interpolator is used with GMASIO?
It's always on. As soon as a frequency discrepancy is noted (such as calibration frequency or speed not at exactly 1.0) the resampling rate is updated, and BASSASIO handles this (to make sure the samples are output at the rate they're supposed to).
Also I understood that a sinc resampler in general would benefit the sound reproduction quality, when resampling a lower rated source (such as from an emulated console) to the PC's 48Khz. Would it as such possibly benefit to have it always on?
If the sound card has issues with playback of lower sampling rates, upsampling to the 'native' sample rate of the card might help. But as a general rule upsampling will not inherently improve quality (we're not adding any information, only guessing what the information might be).
-
If the sound card has issues with playback of lower sampling rates, upsampling to the 'native' sample rate of the card might help. But as a general rule upsampling will not inherently improve quality (we're not adding any information, only guessing what the information might be).
Thanks, good to know how the resampling works with gmasio.
Slightly offtopic, but just asking because maybe you have an opinion on it. Would you in general use the sinc resampler option in an emulator if it's there (like in WinUAE, or BSnes/Higan, and others), or leave it disabled?
Especially for Amiga I've always been in doubt whether it's better or not. Here's an interesting article by the author of the sinc resampler for UAE: https://bel.fi/alankila/modguide/interpolate.txt (https://bel.fi/alankila/modguide/interpolate.txt). The article goes way beyond my understanding, but what I gather from forum posts by him, he argues that the sinc resampling leads to more accurate sound reproduction of the original Amiga audio than not using it. Apparently it should prevent sound aliasing, but to be honest every time I'm comparing the sinc filtered sound of WinUAE versus the unfiltered sound, I'm left in doubt which is the better. With Sinc on there seems to be less aliasing (a slight "metallic"sound) on some samples, but it also seems to muffle the sound very slightly, making it less crisp than my real Amiga (which incidentally sounds both smooth and crisp at the same time..).
-
Let's keep doing this step by step, as it may provide a good test case in general, benefitting other/future users also.
1. What version of ASIO4ALL are you using, do you have the latest version 2.12 (from 7 oct 2014) running?
2. Is the rate for your Realtek playback device configured at 16-bit 48000Hz (the windows default is different from this) and does it have the "allow exclusive mode" ticked? (It's in the Windows audio panel advanced options).
3a. Run the exact same test for ASIO4ALL+Realtek at fd8, but instead of the 512 buffer size, use 96. Please report back with the log.
3b. Run the exact same test for Kx driver + audigy at fd8, buffer size 96. Please report back with the log.
3c. Run the exact same test for ASIO4ALL+Realtek at fd7, buffer size 96. Please report back with the log.
4. Hover your mouse over the asio4all icon in the system tray when you have mame running (pause+alt-tab). Does it show 96 samples or some other value in the mouse over pop-up?
5. Please post a picture of your asio4all configuration panel, with the advanced tab opened (it shows a menu called latency compensation with some options).
6. Could you run intealls latest batool for the realtek audio output (it will be unit 0 or 1 please check). What value does it report?
I was only able to run two more tests this morning. Hopefully I can do the rest by this weekend. I've switched to GMASIO .166 and started with a fresh mame.ini again (Audio_Latency is left at 2 for these tests). Any other changes are listed below.
1. ASIO4ALL 2.12 has been used in all tests I've posted in this thread.
2. Yes. See attachment.
3a See attachment. The result is good. However, I also ran the fd8 test again, and the result was also good. Interesting results.
4. Yes, 96 samples.
5. Screenshot included. I've now set buffer offset to 0 and enabled "Allow Pull Mode" to match Intealls' config.
6. batool result with Asio4all+Realtek
dev 0: ASIO4ALL v2
driver: C:\Program Files (x86)\ASIO4ALL v2\asio4all64.dll
out 0: HD Audio output 1 (group 0, format 18)
out 1: HD Audio output 2 (group 0, format 18)
out 2: HD Audio output 3 (group 0, format 18)
out 3: HD Audio output 4 (group 0, format 18)
out 4: HD Audio output 5 (group 0, format 18)
out 5: HD Audio output 6 (group 0, format 18)
out 6: HD Audio output 7 (group 0, format 18)
out 7: HD Audio output 8 (group 0, format 18)
*Edit - GMASIO .166 would crash when I would try to run windowed, so the ASIO4ALL configuration screenshot was taken while running GMASIO .165. These two tests were run with .166 though.
-
Slightly offtopic, but just asking because maybe you have an opinion on it. Would you in general use the sinc resampler option in an emulator if it's there (like in WinUAE, or BSnes/Higan, and others), or leave it disabled?
I wrote a OpenGL-based wrapper for BASS (ie a module player frontend :) ) a couple of years ago, this discussion has prompted me to dust that off a bit. I usually toggle it around, I prefer without interpolation but after a while it tends to hurt the ears a bit.
You can download it here: https://mega.nz/#!T9RTWRya!98JRpcNnK3eJRFf79k1atMAvmmM-VI5m1jbIRdtv1sY (https://mega.nz/#!T9RTWRya!98JRpcNnK3eJRFf79k1atMAvmmM-VI5m1jbIRdtv1sY)
I compiled three separate binaries for linear, sinc and no filtering. Start it with 'modp-[filterversion].exe [path to your modules]'. If you only want to test it out briefly I added a couple of modules in archive, so place yourself in the same directory as the extracted archive and start it with 'modp-[filterversion].exe .' (note the dot on the end). The P and N keys instantly plays the previous/next song and the R key instantly plays a random song. Otherwise you just navigate with the arrow keys on(pgup/pgdn/home/end also work as they should) and select the song with enter. Also try F5 to toggle between visualizations. I can stare at those things for hours.
Especially for Amiga I've always been in doubt whether it's better or not. Here's an interesting article by the author of the sinc resampler for UAE: https://bel.fi/alankila/modguide/interpolate.txt (https://bel.fi/alankila/modguide/interpolate.txt). The article goes way beyond my understanding, but what I gather from forum posts by him, he argues that the sinc resampling leads to more accurate sound reproduction of the original Amiga audio than not using it. Apparently it should prevent sound aliasing, but to be honest every time I'm comparing the sinc filtered sound of WinUAE versus the unfiltered sound, I'm left in doubt which is the better. With Sinc on there seems to be less aliasing (a slight "metallic"sound) on some samples, but it also seems to muffle the sound very slightly, making it less crisp than my real Amiga (which incidentally sounds both smooth and crisp at the same time..).
Thanks for the text, interesting read although it will probably take me a quite a while to get up to speed with all the content in it. :)
It appears he uses the sinc function to generate BLEP tables, which is something I've never heard about. Some nice info about BLEP can be found here: http://www.slack.net/~ant/bl-synth/ (http://www.slack.net/~ant/bl-synth/)
-
Apparently it should prevent sound aliasing, but to be honest every time I'm comparing the sinc filtered sound of WinUAE versus the unfiltered sound, I'm left in doubt which is the better. With Sinc on there seems to be less aliasing (a slight "metallic"sound) on some samples, but it also seems to muffle the sound very slightly, making it less crisp than my real Amiga (which incidentally sounds both smooth and crisp at the same time..).
The extra "crispiness" you hear without interpolation is probably the resultant high-frequency aliasing. Sometimes this can sound subjectively "better" even though the signal has technically been distorted. The sinc interpolation won't contain the aliasing noise in the top end and may sound a little "duller" compared. Bear in mind were dealing with sound systems that had limited frequency responses and low bandwidth sample playback. The aliasing will be introducing high frequency energy that didn't actually exist in the original signals.
As for your Amiga, there may be some extra analog circuitry at play that has been accounted for in the emulation... I don't know. Then you get into the whole C64 thing were SIDs are re-recorded from specific machines because there were manufacturing variations with SID chips and analog filter networks... phew!
I actually prefer arcade game sounds playing back through the crappy TV speakers in my cab as opposed to my lovely Genelec 8030As (http://www.genelec.com/support-technology/previous-models/8030a-studio-monitor). The cheap speakers act as a band pass filter: removing the muddy low end and softening the scratchy high end of some of these crunchy old sounds systems. Plus, they're akin to the mediocre speakers fitted to most cabs from the era.
Take a look at David Vien's blog (http://ploguechipsounds.blogspot.com/) if you haven't already. He is something of an expert on the aliasing distortion of old DACs and he's a big retro gaming fan too. There are some fascinating articles there...
-
I wrote a OpenGL-based wrapper for BASS (ie a module player frontend :) ) a couple of years ago, this discussion has prompted me to dust that off a bit. I usually toggle it around, I prefer without interpolation but after a while it tends to hurt the ears a bit.
You can download it here: https://mega.nz/#!T9RTWRya!98JRpcNnK3eJRFf79k1atMAvmmM-VI5m1jbIRdtv1sY (https://mega.nz/#!T9RTWRya!98JRpcNnK3eJRFf79k1atMAvmmM-VI5m1jbIRdtv1sY)
OMG that's a very nice player! It has instantly become my favourite modplayer, seriously. Thanks for sharing :)
A few questions: what do the F1, F2 and F3/F4 keys do?
Would you consider adding some features possibly (even if it would be in a future far far away) ?
- A pause button for the music would be nice
- An option for smaller window size, while preserving the topaz aspect would be nice too. That way we would have the possibility to tuck the player away in a corner of the screen, but still watch it.
- A mode where you can press letters a to z to jump through the modlist, that would be useful when the list is very large
Regardless of these, enjoying it greatly as it is! :)
With regards to the interpolation, I think I like the no interpolation the best. But let's see how that fares after listening to (too) many mods...
As for your Amiga, there may be some extra analog circuitry at play that has been accounted for in the emulation... I don't know. Then you get into the whole C64 thing were SIDs are re-recorded from specific machines because there were manufacturing variations with SID chips and analog filter networks... phew!
I think you're definitely right, the analog filters in there give it that special smooth edge (not talking about the original A500 LED ON filter of course as that was horrible, as if you were listening with a pillow strapped over your ears ;) ) Hopefully someday we will have more proper / good working filter additions to the mame drivers, it's definitely an important aspect that is missing currently from the sound emulation.
I was only able to run two more tests this morning. Hopefully I can do the rest by this weekend. I've switched to GMASIO .166 and started with a fresh mame.ini again (Audio_Latency is left at 2 for these tests). Any other changes are listed below.
Great, those are nice results! I see you tested with 0.166, so it could be that the small adjustments that intealls made to the auto calibration routine makes the difference? If you're not too tired of testing, you could test the nrallyx fd8 again with both 0.165 and 0.166, just to make sure whether that's indeed the case.
Just to verify, the nrallyx results for fd7 and fd8, did you test these with or without the asio4all panel buffer offset set to 0 and "Allow Pull Mode" enabled?
The Allow Pull mode is important as it the fastest mode if the audio driver support it. Look closely for the asio4all icon in the system tray when starting mame, the asio4all icon will flash an exclamation mark shortly if pull mode is not supported, otherwise it's fine and you'll be running the fastest mode.
What result do you get if you run "batool64 0 48000"?
Just out of interest, there may be a small chance that ATI powerplay is implemented on your gfx card, that way it may be throttling the vdp is cases where powerplay thinks the game/emulator is not demanding enough (and it's not always right...). I don't think it is the case for the HD48XX series, but it might be interesting to check it.
If you would be interested to verify this, just download the free trialversion of AIDA64 extreme, start it, go to "display" and then "gpu", make sure the correct video card is selected and scroll down below to "ATI Powerplay (BIOS)". It will list the 4 GPU power/speed states. For emulation ideally these are fixed to the same (maximum) rate. I'm not sure which cards have this enabled or not. In the past I had a HD 6780 that screwed up the speed of the PCSX2 emulator in a big way because of this (it kept insisting on switching between the high and medium clock rate, causing regular video stutters in the PCSX emulator, sigh...) . My HD4850 has all speed states the same. Of course there are tools to fix the clockrate, so in case it lists different rates it shouldn't be a real problem.
-
I wrote a OpenGL-based wrapper for BASS (ie a module player frontend :) ) a couple of years ago, this discussion has prompted me to dust that off a bit. I usually toggle it around, I prefer without interpolation but after a while it tends to hurt the ears a bit.
You can download it here: https://mega.nz/#!T9RTWRya!98JRpcNnK3eJRFf79k1atMAvmmM-VI5m1jbIRdtv1sY (https://mega.nz/#!T9RTWRya!98JRpcNnK3eJRFf79k1atMAvmmM-VI5m1jbIRdtv1sY)
OMG that's a very nice player! It has instantly become my favourite modplayer, seriously. Thanks for sharing :)
A few questions: what do the F1, F2 and F3/F4 keys do?
Thanks :) I wrote it for myself since I wanted a more fun way to listen and go through the vast thing that is modland (ordinary Windows players are just so... dull). Someday I might add support for FTP, so the mods will be fetched from the modland servers.
The F2 button autoincrements randomly-ish (need to seed the random number generator for proper randomness).
For looping modules, the F3 and F4 buttons set the minimum length. So if a module is only 15 seconds long a mlth value of 60 makes it loop 4 times before fading to the next song.
- A pause button for the music would be nice
Already in there, mash space. :)
- An option for smaller window size, while preserving the topaz aspect would be nice too. That way we would have the possibility to tuck the player away in a corner of the screen, but still watch it.
Try F8, F9 and F10. :)
- A mode where you can press letters a to z to jump through the modlist, that would be useful when the list is very large
I agree, this would be a very nice feature to have.
Given time I should really clean up the code a bit and post it somewhere.
Edit: Also you can use backspace to go to the previous folder when browsing. So it's quite quick to navigate with pgup/pgdn/home/end and use backspace to go to the previous folder.
-
Just to verify, the nrallyx results for fd7 and fd8, did you test these with or without the asio4all panel buffer offset set to 0 and "Allow Pull Mode" enabled?
The Allow Pull mode is important as it the fastest mode if the audio driver support it.
I'm not sure how I missed this. Yes, my last post was with both those settings changed. I actually have now run multiple tests at FD8 with ASIO4ALL set to 64 and audio_latency 1.0, including Neo Geo games (Attached). Without allow pull mode, there is constant crackling. It's a night/day difference. GMASIO .165 seems fine as well. Here's the BATool result.
dev 0: ASIO4ALL v2
driver: C:\Program Files (x86)\ASIO4ALL v2\asio4all64.dll
out 0: HD Audio output 1 (group 0, format 18)
out 1: HD Audio output 2 (group 0, format 18)
out 2: HD Audio output 3 (group 0, format 18)
out 3: HD Audio output 4 (group 0, format 18)
out 4: HD Audio output 5 (group 0, format 18)
out 5: HD Audio output 6 (group 0, format 18)
out 6: HD Audio output 7 (group 0, format 18)
out 7: HD Audio output 8 (group 0, format 18)
QPC frequency is 3579545
measuring device ASIO4ALL v2 with latency 108 and sample rate 48000.00
rate is currently determined to be 47999.96 Hz
rate has converged in 16.4 seconds.
This is better than I remember achieving when I first tested months ago...anyway, I think I'm going to give up on the Audigy RX in light of these results. There are a variety of issues with it, including severely overdriven audio at max volume. I have to drop to 50% volume to resolve this. I suppose I can't expect a custom driver that was written well before the card existed to work perfectly. Thank you all again. This is a big improvement over what I was working with!
-
Just to verify, the nrallyx results for fd7 and fd8, did you test these with or without the asio4all panel buffer offset set to 0 and "Allow Pull Mode" enabled?
The Allow Pull mode is important as it the fastest mode if the audio driver support it.
I'm not sure how I missed this. Yes, my last post was with both those settings changed. I actually have now run multiple tests at FD8 with ASIO4ALL set to 64 and audio_latency 1.0, including Neo Geo games (Attached). Without allow pull mode, there is constant crackling. It's a night/day difference. GMASIO .165 seems fine as well. Here's the BATool result.
Thank you for verifying this. I also use the ASIO4ALL+Realtek combo on my GM rig, since it just works so good.
This is better than I remember achieving when I first tested months ago...anyway, I think I'm going to give up on the Audigy RX in light of these results. There are a variety of issues with it, including severely overdriven audio at max volume. I have to drop to 50% volume to resolve this. I suppose I can't expect a custom driver that was written well before the card existed to work perfectly. Thank you all again. This is a big improvement over what I was working with!
Yes, the Rx card isn't really supported with kX. Here's a thread with info on it: http://www.hardwareheaven.com/community/threads/help-with-kx-drivers-and-the-new-audigy-5-sb1550.226143/ (http://www.hardwareheaven.com/community/threads/help-with-kx-drivers-and-the-new-audigy-5-sb1550.226143/). Someone in that thread reported that you could use a PCI to PCIe bridge chip with an older card, if the mainboard lacks a PCI slot. But since ASIO4ALL + Realtek works so good I wonder if it's worth it.
-
I think you're definitely right, the analog filters in there give it that special smooth edge (not talking about the original A500 LED ON filter of course as that was horrible, as if you were listening with a pillow strapped over your ears ;) )
Have you seen this? http://sourceforge.net/projects/equalizerapo/ (http://sourceforge.net/projects/equalizerapo/). Unfortunately it doesn't work with ASIO or WASAPI exclusive, but it's still great fun to play around with. You could try running modp-nointer and add a low-pass filter around 5000 Hz, to see if it comes closer to sounding like the Amiga.
-
Updated to 0.167. No major changes.
-
Awesome. Thanks for the quick update!
-
Updated to 0.167. No major changes.
Hi,
I see ASIO as a very promising feature for Windows users. Under Linux, groovymame is still waiting for such low latency feature with pitch perfect audio ;-) Well done.
Would it be possible to make the different timing logs available for other drivers? I would like to experiment how Linux behave with ALSA.
Rgds,
-
Updated to 0.167. No major changes.
Under Linux, groovymame is still waiting for such low latency feature with pitch perfect audio ;-) Well done.
I've noticed that ALSA seems a lot tighter than Direct Sound. So the return of investment seems smaller on Linux than on Windows.
Would it be possible to make the different timing logs available for other drivers? I would like to experiment how Linux behave with ALSA.
Sure, I'll see if I can cobble something together.
Edit: updated the post with a patch and Octave script which enables some logging with the SDL interface.
-
Edit: updated the post with a patch and Octave script which enables some logging with the SDL interface.
Thanks a lot intealls, I will build a groovymame test version and report here :-)
Cheers
-
@intealls, you have definitely added pepper on the Linux soup. With your patch, I can now track the speed emulation issue and look around how to fix it. As a first example, this is how a neogeo game (Windjammers) behaves. At the moment it looks chaotic.
Snap 1: ubuntu PC (LCD GLSL)
Snap 2: groovyarcade groovymame_0167.015j 15KHz
-
@intealls, you have definitely added pepper on the Linux soup. With your patch, I can now track the speed emulation issue and look around how to fix it. As a first example, this is how a neogeo game (Windjammers) behaves. At the moment it looks chaotic.
Snap 1: ubuntu PC (LCD GLSL)
Snap 2: groovyarcade groovymame_0167.015j 15KHz
Hm. The first one (Ubuntu LCD) does seem to be in order. The audio issues are in line with with the speed variations. Are you using syncrefresh with this setup? Also, is PulseAudio enabled?
The second one is trickier though. It *looks* like a calibration frequency issue (i.e. the sound card is not requesting samples at 48000 Hz), but I can't be sure.
What are the hardware configurations for these setups?
-
Let's start with embedded audio controller on a nforce based motherboard. Here is the default SLD alsa audio configuration.
Audio hardware:
Realtek ALC262
Audio device: NVIDIA Corporation MCP73 High Definition Audio (rev a1)
# cat /proc/asound/card0/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 1024
buffer_size: 16384
Groovymame log:
Audio: Start initialization
Audio: Driver is alsa
Audio: frequency: 48000, channels: 2, samples: 1024
sdl_create_buffers: creating stream buffer of 18432 bytes
Audio: End initialization
I can see that we can have underrun
ALSA lib pcm.c:7905:(snd_pcm_recover) underrun occurred
-
I suspect that the issue is the calibration frequency.
GM uses the soundsync functionality which dynamically adjusts the rate at which the sound system is fed samples depending on game speed.
There's another issue here, one that shouldn't really be an issue but is, which is the rate that the sound card actually plays samples. Sound systems in general claim to use 48000 samples/sec (or 44100/sec etc), but in practice this can deviate quite a bit.
I've solved this with ASIO implementation with a linear estimation of the playback frequency, which is then used for resampling the audio. This in itself poses a number of difficulties. Sometimes for short periods of time some drivers just won't request any samples at all, or too many, which will throw off the algorithm. The main difficulty is detecting when the calibration frequency gets invalid due to aformented issues, the ASIO implementation still needs some work in regards to this.
ASIO also disables soundsync, and uses a higher quality resampling algorithm provided by BASSASIO. The resampling takes into account the rate at which the sound system is given samples (game speed), as well as the playback frequency of the sound card, which at least in theory should lead to neither underruns nor overruns.
So to summarize, to fix the issues, you need to find the rate at which samples are requested by the sound system. You then need to resample the audio in some way, I haven't investigated eventual possibilities already built into MAME, since BASSASIO is nice enough to provide an excellent resampler already. RA has a resampler which is similar to the one in BASSASIO.
-
Hi,
I made several tests and looked as the audio RT feature from the kernel/daemon side to see how far buffer and latency could be optimized. ALSA combined to SDL2 framework is currently optimized for low latency and uses the buffering ring as expected without thread (context switching) synchronisation issue.
In fact, you have already addressed the point with your ASIO implementation inside MAME. The only way to have the current ASIO benefit under Linux, is to rewrite the way the system is calculating the samples stream against the frequency.
Some other sound protocol like JACK have ASIO like API but are all based on ALSA. ALSA is already low latency oriented and the only element to do is to put the re-sampling inside the the MAME sound library.
At the moment, I do not have enough time to dedicate for a full development cycle, but I can offer help on the testing, programming and verification side. If someone is interested to jump in that topic and start the investigation....
Cheers
-
If you want to experiment with the existing resampler, you could play around in the following files. You can expect rounding errors however, which could possibly be fixed by understanding and altering the resampling function (sound_stream::generate_resampled_data(stream_input&, UINT32) I think).
+++ b/src/emu/sound.h
@@ -54,7 +54,6 @@ class sound_stream
{
friend class simple_list<sound_stream>;
friend class sound_manager;
+ friend class speaker_device;
typedef void (*stream_update_func)(device_t *device, sound_stream *stream, void *param, stream_sample_t
+++ b/src/emu/speaker.c
void speaker_device::mix(INT32 *leftmix, INT32 *rightmix, int &samples_this_update...
...
if (m_mixer_stream == NULL)
return;
+ m_mixer_stream->set_sample_rate((2.0 - machine().video().speed_percent()) * machine().sample_rate());
+ m_mixer_stream->apply_sample_rate_changes();
-
Is there a way to use Kernel Streaming instead of ASIO on windows XP?
I don't have an ASIO compatible audio card (it's the one integrated on the motherboard, a Realtek HD something) and I'd rather not use ASIO4ALL as it has been much of an hit or miss for me in lots of situations.
Bypassing the windows mixer would be a nice step up.
-
Is there a way to use Kernel Streaming instead of ASIO on windows XP?
I don't have an ASIO compatible audio card (it's the one integrated on the motherboard, a Realtek HD something) and I'd rather not use ASIO4ALL as it has been much of an hit or miss for me in lots of situations.
My guess is that ASIO4ALL uses kernel streaming on XP.
Also, please read the first post.
-
Bump to 0.168.
-
My guess is that ASIO4ALL uses kernel streaming on XP.
Also, please read the first post.
It does indeed, but also does other things which often mess up with the various systems I've tried it on (actually, I use wasapi on windows 7) so I asked because I was looking for a "clean" solution.
As we speak, I've been using Virtual Audio Cable to bypass the windows mixer and use kernel streaming but it's an inelegant solution, if you will.
How hard is it to tell MAME to use the kernel streaming API on windows xp as audio output rather than hijacking the audio stream via ASIO4ALL/Virtual Audio Cable/etc... ?
-
How hard is it to tell MAME to use the kernel streaming API on windows xp as audio output rather than hijacking the audio stream via ASIO4ALL/Virtual Audio Cable/etc... ?
In regards to mainline MAME, there appears to be discussions of integrating PortAudio. If this is done (which is different from what I'm doing with BASSASIO), it *might* be possible to use the kernel streaming API.
Not using PortAudio and writing your own backend is probably fairly time-consuming.
-
In regards to mainline MAME, there appears to be discussions of integrating PortAudio. If this is done (which is different from what I'm doing with BASSASIO), it *might* be possible to use the kernel streaming API.
I've heard that, hopefully they'll go that way. Once done integrating KS should be possible without too many hassles.
I found lot of time ago someone discussing about that, but it's from 2004 so there's that:
https://github.com/mamedev/mame/blob/master/3rdparty/portaudio/src/hostapi/wdmks/readme.txt
not sure what happened then.
Not using PortAudio and writing your own backend is probably fairly time-consuming.
Definitely.
EDIT: looks like something is definitely moving: https://github.com/mamedev/mame/tree/master/3rdparty/portaudio
and it supports a lots of APIs, not only KS but wasapi too!
-
I'm not sure if this has been discussed before, I wasn't able to find anything in search.
Today, after a year of neglect, I updated everything to version 168. When compiling the new mame I added ASIO to see how far its come along since last time I tried it. (It did't work well with frame delay back then)
All the games that I tried worked fantastic but my only problem now is with my frontend, Hyperspin. When I first boot up Hyperspin, I have sound. Load up a game in Mame, I have sound. Now when I exit back into Hyperspin, the frontend no longer has sound. Load another Mame game and I have sound again. Exit back out into Hyperspin, no sound.
Was curious if anyone else has had this problem?
Thanks.
-
All the games that I tried worked fantastic but my only problem now is with my frontend, Hyperspin. When I first boot up Hyperspin, I have sound. Load up a game in Mame, I have sound. Now when I exit back into Hyperspin, the frontend no longer has sound. Load another Mame game and I have sound again. Exit back out into Hyperspin, no sound.
What sound card/driver are you using?
-
Yea, I didn't think about posting my system info till I laid down in the bed.
I'm at work right now so hope I'm remembering right.
It's an integrated soundmax hd, using asio4all 2.13 and asio 168 diff.
Something curious I noticed after I had posted was it seems its the asio4all program that's at fault, if I open up asio4all offline settings while I'm watching a YouTube video inside of a browser all of the sound will stop working.
I'll be off work in a few hours so I'll be a little more available to help with any info you need. I hate posting from a phone lol.
-
Something curious I noticed after I had posted was it seems its the asio4all program that's at fault, if I open up asio4all offline settings while I'm watching a YouTube video inside of a browser all of the sound will stop working.
Figured it might be something like this. Try updating the driver, if possible.
ASIO accesses the sound card directly, and if the driver doesn't handle this properly this is one of the issues that can occur. For example, the Xonar U7 silences all other applications when using ASIO, and resumes them when ASIO is no longer used.
On my laptop, some of the time, ASIO4ALL won't start when another application is using the sound card (IDT HD codec). I haven't experienced any issues with the Realtek+ASIO4ALL combo however (and luckily this is a common configuration).
-
Ok thanks.
I have an old Audigy 2 that I could put in the computer, do you think that would be a better route or am I better off trying to troubleshoot the integrated card first?
-
I have an old Audigy 2 that I could put in the computer, do you think that would be a better route or am I better off trying to troubleshoot the integrated card first?
Try updating the driver first, also check if you can find an updated driver from the manufacturer of the chip (Analog Devices?). If you decide to try the Audigy, I'd recommend using kX 3551 which you can find here: http://www.hardwareheaven.com/community/threads/3551-alpha-released.206609/ (http://www.hardwareheaven.com/community/threads/3551-alpha-released.206609/).
There's also the possibility that Hyperspin is to blame (probably not the case since it seems to break with YouTube as well), however I haven't tested it since it's too much of a hassle to set up, but if anyone's using ASIO with Hyperspin please drop a comment if it works properly or not.
-
All the drivers seemed to be up to date. Oh well.
I installed the Audigy 2 and the kx project drivers. Ran batool64 got the cal freq and set it to 96 bytes. I didn't have a large amount of time to play around but everything seems to be working fine. The kx project control panel could use some working on though! lol!
-
All the drivers seemed to be up to date. Oh well.
I installed the Audigy 2 and the kx project drivers. Ran batool64 got the cal freq and set it to 96 bytes. I didn't have a large amount of time to play around but everything seems to be working fine. The kx project control panel could use some working on though! lol!
Great, also, you shouldn't need to set the cal freq anymore. This is handled automatically since a few releases back.
-
Ah ok, so just set it back to 0.0?
-
Ah ok, so just set it back to 0.0?
Yup. Also, if you have platformclock enabled, you can disable it since the correct frequency is found regardless of its setting. (The frequency seems to change when QueryPerformanceCounter switches clocks)
-
Bump to the utterly awesome 0.169/0.15l. Great job Calamity!
-
It seems like i can't get sync with the latest version.
The official groovymame works just fine but this one seems to lose sync.
I am using the regular crt emudriver, not the new ones.
Tried changing presets in the ini but the problem persists.
Also tried starting from scratch as far as settings go and still can't get the tv to sync with this version.
P.S: Just wanted to say that this asio implementation is just awesome, coupled with xonar d2x i'm getting an insanely low audio latency, lower than 32ms, it's amazing!
-
It seems like i can't get sync with the latest version.
The official groovymame works just fine but this one seems to lose sync.
I am using the regular crt emudriver, not the new ones.
Tried changing presets in the ini but the problem persists.
Also tried starting from scratch as far as settings go and still can't get the tv to sync with this version.
P.S: Just wanted to say that this asio implementation is just awesome, coupled with xonar d2x i'm getting an insanely low audio latency, lower than 32ms, it's amazing!
Thanks!
Ok, I'll bump it to 0.169 final which will most likely solve the issues.
-
Bump to 0.169 final, please report if this fixes the issues.
-
Seems to work perfectly now.
Thank you.
Edit: And of course Calamity!
-
Seems to work perfectly now.
Thank you.
Don't thank me, thank Calamity. :)
-
P.S: Just wanted to say that this asio implementation is just awesome, coupled with xonar d2x i'm getting an insanely low audio latency, lower than 32ms, it's amazing!
You should be able to go much lower than that, with my Xonar DGX I can hit 1 ms latency. However, the Xonar ASIO drivers I've tested are all really buggy (faint crackling etc) - you might be better off with ASIO4ALL if you have a Realtek chip on your motherboard.
-
Actually, i am using 1ms, and it works perfectly for me, using regular drivers and win7 x64, no crackling or anything like that.
Edit: BTW, how low can you go with asio4all and realtek?
-
Well, i've tried asio4all with realtek and also nvidia hdmi audio on my main rig, was able to pull 64 samples which, if i understand correctly, equals to about 1-2 ms, pretty awesome.
Alas it seems to cause problems with hyperspin.
After exiting mame i would get no sound in hyperspin, happens with the realtek chip and nvidia.
Any solutions for that?
With xonar d2x that problem doesn't exist.
Edit: Seems like the same problem timply had.
I'm pretty sure the problem isnt with asio4all per se but rather the fact it takes exclusive control of the sound card,
i had a similar problem with mednafen when used in wasapi mode, though with mednafen i didn't mind using the wasapi shared mode since the difference was negligible, so i never tried fixing that.
Hopefully i'll be able to find a way to fix this.
-
Edit: Seems like the same problem timply had.
I'm pretty sure the problem isnt with asio4all per se but rather the fact it takes exclusive control of the sound card,
i had a similar problem with mednafen when used in wasapi mode, though with mednafen i didn't mind using the wasapi shared mode since the difference was negligible, so i never tried fixing that.
Hopefully i'll be able to find a way to fix this.
Correct, it's up to the sound card driver. It's worth a try to update the Realtek driver to see if it fixes the problem.
With the Xonar DGX I got faint crackling in some games (Deathsmiles for instance), but if you don't know about it you'll probably not notice it. The Xonar U7 seems to have a bug in the driver that sometimes crashes MAME upon exit. I'm not sure the Xonar D2X behaves the same. From all my testing though, the ASIO4ALL+Realtek combo undoubtedly gives the most stable performance, so it's worth looking into, but general sound quality might be better with the D2X.
The main reason for using ASIO4ALL is if you're getting over/underruns when you shouldn't. You could check if the D2X behaves by starting GM from the command line as such 'mame64 samsho4 -str 900 -v -asio_log -fd 1 -video d3d'. This will run the game for fifteen minutes. If you're not getting any over/underruns with this configuration (or very few of them), it's probably not worth the time spent to get ASIO4ALL working correctly. You should be seeing 'ASIO: Overrun/underrun: x/y' near the end of the log.
Actually, i am using 1ms, and it works perfectly for me, using regular drivers and win7 x64, no crackling or anything like that.
Edit: BTW, how low can you go with asio4all and realtek?
I'm seeing the same excellent result as you - 64 samples is very stable on the PCs I've tested it on.
-
Well, just tried several realtek drivers, the ones from my motherboard's site (Gigabyte), from realtek and even the default microsoft ones, and nada, still not working. :angry:
The main reason i use ASIO4ALL is because the d2x is installed on my emulation pc.
I'm trying to use ASIO4ALL for my main pc which only has realtek and nvidia hdmi audio.
I wonder if there's at least a workaround for this.
With hyperspin and rlauncher i can run a command after exiting mame using User Functions.ahk, maybe there's a way to restore the sound using that?
-
Well, just tried several realtek drivers, the ones from my motherboard's site (Gigabyte), from realtek and even the default microsoft ones, and nada, still not working. :angry:
Ok, thanks for reporting. I'll see if I can install Hyperspin and find a workaround.
Edit: What ASIO4ALL settings are you using btw (pull mode etc)?
-
Using the same settings like in the first page, pull mode checked, 64 samples, no latency compensation or anything like that, tried without pull mode either, buffer offset 0ms, force wdm driver 16 bit and always resample unchecked.
In the mean time, i remembered having an old sb audigy 4 in my old pc, just took it out and preparing to install it on this pc.
BTW, the realtek i am using is alc887, which is pretty common.
Motherboard: GA-B85M-HD3 http://www.gigabyte.com/products/product-page.aspx?pid=4568#sp (http://www.gigabyte.com/products/product-page.aspx?pid=4568#sp)
Thank you for your help.
-
Using the same settings like in the first page, pull mode checked, 64 samples, no latency compensation or anything like that, tried without pull mode either, buffer offset 0ms, force wdm driver 16 bit and always resample unchecked.
In the mean time, i remembered having an old sb audigy 4 in my old pc, just took it out and preparing to install it on this pc.
BTW, the realtek i am using is alc887, which is pretty common.
Motherboard: GA-B85M-HD3 http://www.gigabyte.com/products/product-page.aspx?pid=4568#sp (http://www.gigabyte.com/products/product-page.aspx?pid=4568#sp)
Thank you for your help.
Ok, thank you for testing and the information. I just tested HS (it was actually easier to get to run than I thought), and it appears to do the same thing with my Xonar U7.
I have no experience with the Audigy 4, but it will hopefully work if there are ASIO drivers for Windows 7 etc.
Edit: I was able to get it working with the Xonar U7 if I disabled 'Allow applications to take exclusive control over this device' in the Advanced sound settings pane, which probably shouldn't work, but did. It didn't work with ASIO4ALL+Realtek. At this point, I don't know. The Hyperspin devs obviously haven't thought of this scenario, DirectSound (or whatever they're using) should be released at emulator start, and reopened at emulator exit. Since ASIO (and perhaps WASAPI as well) is so rarely used for emulators they can't really be blamed for it either.
There's an application that will solve the issue however, but it's insanely overkill and expensive for simply solving the issue at hand, it can be found here: http://odeus-audio.com.au/Odeus/ASIOLinkPro (http://odeus-audio.com.au/Odeus/ASIOLinkPro).
-
Well, i've installed the card, tried offical drivers first, it allows to go as low as 2ms, but i have a strong feeling that the latency is in fact higher than 2ms, it's really hard to tell but it just doesn't feel like 2ms, with the realtek and asio4all or xonar d2x it feels lower. Maybe it's placebo, who knows.
At the current moment i've installed the kX drivers, they were a bit of a pain to install but got them to work.
The settings are horrendous, really horrible lol.
Surprisingly it allows to go as low as 32 samples (0.67ms) but it sounds horrible. 64 samples, on the other hand, sounds perfect.
Any tips about those drivers? that gui is confusing as hell. So far i had to swap front and rear speakers and configure the asio settings, other than that haven't touched anything else.
Any preferred settings for the asio format and sync?
-
Well, i've installed the card, tried offical drivers first, it allows to go as low as 2ms, but i have a strong feeling that the latency is in fact higher than 2ms, it's really hard to tell but it just doesn't feel like 2ms, with the realtek and asio4all or xonar d2x it feels lower. Maybe it's placebo, who knows.
At the current moment i've installed the kX drivers, they were a bit of a pain to install but got them to work.
The settings are horrendous, really horrible lol.
Surprisingly it allows to go as low as 32 samples (0.67ms) but it sounds horrible. 64 samples, on the other hand, sounds perfect.
Any tips about those drivers? that gui is confusing as hell. So far i had to swap front and rear speakers and configure the asio settings, other than that haven't touched anything else.
Any preferred settings for the asio format and sync?
Ok, does HS work properly with kX?
Yes, the GUI does take some getting use to. :) But once you do, it's hard not to love it. Also, kX for some reason seem to switch the front and rear jacks so it might be easier to simply switch those at the card, than configuring it to use the rear. There's also a real-time equalizer that affects all sound coming out of the card, including ASIO, which is terrific for headphones. The only reason I switched over to the Xonar U7 is that kX is a bit wonky under W10, and the original developer is no longer maintaining it. Under W7 though it's great, if you use 'kX WaveOut 2/3' as speaker, using the 'kX Master Mixer' might lead to problems.
You should leave the sync settings at the default, a lot of work has been put in to the ASIO implementation to make it work well with the default setting.
-
Ok, does HS work properly with kX?
Yes, the GUI does take some getting use to. :) But once you do, it's hard not to love it. Also, kX for some reason seem to switch the front and rear jacks so it might be easier to simply switch those at the card, than configuring it to use the rear. There's also a real-time equalizer that affects all sound coming out of the card, including ASIO, which is terrific for headphones. The only reason I switched over to the Xonar U7 is that kX is a bit wonky under W10, and the original developer is no longer maintaining it. Under W7 though it's great, if you use 'kX WaveOut 2/3' as speaker, using the 'kX Master Mixer' might lead to problems.
You should leave the sync settings at the default, a lot of work has been put in to the ASIO implementation to make it work well with the default setting.
Well, HS works properly with kX and official sb drivers.
Also, i think i found out why the official drivers won't go lower than 2ms. With the kX drivers installed the only way to get 1.33ms (64 samples) working properly without crackles and etc, i have to set a different audio card as the default sound card and only use the audigy for asio. If i set the audigy as the default audio card i have to set the latency to 2ms or else i get crackles and etc. Weird. Just to be clear, the audigy is the only one with asio support, the others can only work with ASIO4ALL, which is not installed. I'm stating that to make sure that you don't think that mame uses different asio driver because i changed the default audio device.
All at all, i'm thinking about removing the kX drivers and going with the official ones. Assuming i only care about fidelity and not equalizer settings and etc which driver would be the best choice?
In other words, is there a difference in the sound quality between the two drivers, fidelity wise?
EDIT: And about what i said earlier with the sb drivers having higher latency, that was my fault, my receiver was set to a delay of 20ms because it was connected to a different input.
-
Well, HS works properly with kX and official sb drivers.
Also, i think i found out why the official drivers won't go lower than 2ms. With the kX drivers installed the only way to get 1.33ms (64 samples) working properly without crackles and etc, i have to set a different audio card as the default sound card and only use the audigy for asio.
I've never seen this, weird. Are you using W10 or W7, and Audigy 4? The Audigy 4 is listed as 'partially supported' with kX, so it might be buggy.
Just to be clear, the audigy is the only one with asio support, the others can only work with ASIO4ALL, which is not installed. I'm stating that to make sure that you don't think that mame uses different asio driver because i changed the default audio device.
It won't change the ASIO device, you need to specify this with the '-asio_device x' setting. If you start a command prompt you can use the included batool64 to list what ASIO drivers are available.
If you run GM with '-v -asio_log' you also get information about what ASIO driver is being used.
All at all, i'm thinking about removing the kX drivers and going with the official ones. Assuming i only care about fidelity and not equalizer settings and etc which driver would be the best choice?
If the official SB drivers work, use them if you don't need anything extra from kX. If you're getting over/underruns with the official ones when you shouldn't, you could try the kX driver. The reason I'm recommending the kX driver is that I've done many, many tests with it, but only with fully supported cards (Audigy 2/Live!).
In other words, is there a difference in the sound quality between the two drivers, fidelity wise?
Nope, there shouldn't be a difference between the two.
-
I'm using win7 x64.
And thank you for your help.
-
I'm using win7 x64.
And thank you for your help.
Thanks and no problem. Please report back if the original SB driver works properly.
-
So far it works properly, but only allows to go as low as 96 samples.
Edit: results from runnimg smasho4 with your settings,
I:\Hyperspin\Emulators\Mame>mame64 samsho4 -str 900 -v -asio_log -fd 1 -video d3
d
SwitchRes: v0.015l, Monitor: lcd, Orientation: horizontal, Modeline generation:
disabled
SwitchRes: Using default vfreq range for LCD 59.000000-61.000000
SwitchRes: \\.\DISPLAY1: NVIDIA GeForce GTX 660 (PCI\VEN_10DE&DEV_11C0&SUBSYS_
354E1458&REV_A1)
SwitchRes: Device key: System\CurrentControlSet\Control\Video\{3B7E4324-B082-457
8-8488-6B1EF016122E}\0000
Video chipset is not compatible.
Switchres: Searching for custom video modes...
Switchres: [ 1] 640x 480 @ 60 : system mode
Switchres: [ 2] 640x 480 @ 75 : system mode
Switchres: [ 3] 800x 600 @ 60 : system mode
Switchres: [ 4] 800x 600 @ 75 : system mode
Switchres: [ 5] 1024x 768 @ 60 : system mode
Switchres: [ 6] 1024x 768 @ 75 : system mode
Switchres: [ 7] 1176x 664 @ 50 : system mode
Switchres: [ 8] 1176x 664 @ 60 : system mode
Switchres: [ 9] 1176x 664 @ 59 : system mode
Switchres: [ 10] 1280x1024 @ 60 : system mode
Switchres: [ 11] 1280x1024 @ 75 : system mode
Switchres: [ 12] 1600x1200 @ 60 : system mode
Switchres: [ 13] 1768x 992 @ 25 : system mode
Switchres: [ 14] 1768x 992 @ 30 : system mode
Switchres: [ 15] 1768x 992 @ 29 : system mode
Switchres: [ 16] 1920x1200 @ 59 : system mode
Switchres: [ 17] 1920x1200 @ 60 : system mode
Switchres: [ 18] 1920x1080 @ 60* : system mode
Switchres: [ 19] 1920x1080 @ 59 : system mode
Switchres: [ 20] 1920x1080 @ 30 : system mode
Switchres: [ 21] 1920x1080 @ 29 : system mode
Switchres: [ 22] 1920x1080 @ 50 : system mode
Switchres: [ 23] 1920x1080 @ 25 : system mode
Switchres: [ 24] 1920x1080 @ 24 : system mode
Switchres: [ 25] 1920x1080 @ 23 : system mode
Switchres: [ 26] 1280x 720 @ 60 : system mode
Switchres: [ 27] 1280x 720 @ 59 : system mode
Switchres: [ 28] 1280x 720 @ 50 : system mode
Switchres: [ 29] 720x 480 @ 60 : system mode
Switchres: [ 30] 720x 480 @ 59 : system mode
Switchres: [ 31] 720x 576 @ 50 : system mode
Switchres: [ 32] 1152x 864 @ 75 : system mode
SwitchRes: Found 0 custom of 32 active video modes
SwitchRes: Creating automatic specs for LCD based on VESA GTF
SwitchRes: Monitor range 65962.00-68198.00,59.00-61.00,0.741,1.157,1.898,0.015,0
.045,0.507,0,1,1080,1080,0,0
SwitchRes: -resolution was forced as 1920x1080@60
SwitchRes: Entering switchres_modeline_setup
SwitchRes: v0.015l:[samsho4] Calculating best video mode for 320x224@59.185608 o
rientation: normal
SwitchRes: [ 640]x[ 480]_(60=60.000000Hz) - locked
SwitchRes: [ 640]x[ 480]_(75=75.000000Hz) - locked
SwitchRes: [ 800]x[ 600]_(60=60.000000Hz) - locked
SwitchRes: [ 800]x[ 600]_(75=75.000000Hz) - locked
SwitchRes: [1024]x[ 768]_(60=60.000000Hz) - locked
SwitchRes: [1024]x[ 768]_(75=75.000000Hz) - locked
SwitchRes: [1176]x[ 664]_(50=50.000000Hz) - locked
SwitchRes: [1176]x[ 664]_(60=60.000000Hz) - locked
SwitchRes: [1176]x[ 664]_(59=59.000000Hz) - locked
SwitchRes: [1280]x[1024]_(60=60.000000Hz) - locked
SwitchRes: [1280]x[1024]_(75=75.000000Hz) - locked
SwitchRes: [1600]x[1200]_(60=60.000000Hz) - locked
SwitchRes: [1768]x[ 992]_(25=25.000000Hz) - locked
SwitchRes: [1768]x[ 992]_(30=30.000000Hz) - locked
SwitchRes: [1768]x[ 992]_(29=29.000000Hz) - locked
SwitchRes: [1920]x[1200]_(59=59.000000Hz) - locked
SwitchRes: [1920]x[1200]_(60=60.000000Hz) - locked
SwitchRes: [1920]x[1080]_(60=60.000000Hz)
rng(0): 1920 x1080_60.000000p 0.000000 [fract] scale(6, 4, 1) diff(0.00, 16.6
5, 0.0000) ratio(6.000, 4.821)
SwitchRes: [1920]x[1080]_(59=59.000000Hz) - locked
SwitchRes: [1920]x[1080]_(30=30.000000Hz) - locked
SwitchRes: [1920]x[1080]_(29=29.000000Hz) - locked
SwitchRes: [1920]x[1080]_(50=50.000000Hz) - locked
SwitchRes: [1920]x[1080]_(25=25.000000Hz) - locked
SwitchRes: [1920]x[1080]_(24=24.000000Hz) - locked
SwitchRes: [1920]x[1080]_(23=23.000000Hz) - locked
SwitchRes: [1280]x[ 720]_(60=60.000000Hz) - locked
SwitchRes: [1280]x[ 720]_(59=59.000000Hz) - locked
SwitchRes: [1280]x[ 720]_(50=50.000000Hz) - locked
SwitchRes: [ 720]x[ 480]_(60=60.000000Hz) - locked
SwitchRes: [ 720]x[ 480]_(59=59.000000Hz) - locked
SwitchRes: [ 720]x[ 576]_(50=50.000000Hz) - locked
SwitchRes: [1152]x[ 864]_(75=75.000000Hz) - locked
SwitchRes: [samsho4] (1) horizontal (320x224@59.185608)->(1920x1080@60.000000)
rng(0): 1920 x1080_60.000000p 0.000000 [fract] scale(6, 4, 1) diff(0.00, 16.6
5, 0.0000) ratio(6.000, 4.821)
SwitchRes: Setting option -rotate
SwitchRes: Setting option -noror
SwitchRes: Setting option -autoror
SwitchRes: Setting option -norol
SwitchRes: Setting option -noautorol
SwitchRes: Setting option -noblack_frame_insertion
SwitchRes: Setting option -multithreading
SwitchRes: Setting option -notriplebuffer
SwitchRes: Setting option -syncrefresh
SwitchRes: Setting option -waitvsync
SwitchRes: Setting option -nohwstretch
SwitchRes: Setting option -keepaspect
SwitchRes: Setting option -filter
SwitchRes: Setting option -prescale 1
Video: Monitor 00000000083EC4A8 = "\\.\DISPLAY1" (primary)
Direct3D: Using Direct3D 9
window_proc: WM_NCACTIVATE
blit_lock = TRUE
Physical width 1920, height 1080
Direct3D: Configuring adapter #0 = NVIDIA GeForce GTX 660
Direct3D: Adapter has Vendor ID: 10DE and Device ID: 11C0
Direct3D: Using dynamic textures
Direct3D: YUV format = RGB
Direct3D: Max texture size = 16384x16384
Direct3D: Device created at 1920x1080
Direct3D: First scanline: 0, Last scanline: 1079, Break scanline: 979, Delay sca
nline: 0
blit_unlock = TRUE
window_proc: WM_PAINT
Blitting thread created
winwindow_video_window_create: blit_lock = TRUE
Blitting thread started
RawInput: APIs detected
Input: Adding Mouse #0: HID-compliant mouse
Input: Adding Gun #0: HID-compliant mouse
Input: Adding Kbd #0: HID Keyboard Device
Input: Adding Mouse #1: HID-compliant mouse
Input: Adding Gun #1: HID-compliant mouse
Input: Adding Kbd #1: HID Keyboard Device
DirectInput: Using DirectInput 8
blit_lock = FALSE
window_proc: WM_PAINT:END
Input: Adding Joy #0: MotioninJoy Virtual Game Controller
ASIO: Game is running at 59.185608 Hz, screen at about 60.000000 Hz
ASIO: Driver SB Audigy 4 ASIO [C000] initialized with latency 96,
sample rate 48000.00, compensated sample rate 0.000000,
driver version: 2, bufmin: 96, bufmax: 65536,
bufpref: 96, bufgran: 16
audio latency is 1
frame delay is 1
ASIO: Setting initial playback rate to 48000.000 Hz
Region ':maincpu' created
Region ':fixed' created
Region ':fixedbios' created
Region ':zoomy' created
Region ':mainbios' created
Region ':audiobios' created
Region ':audiocpu' created
Region ':ymsnd' created
Region ':sprites' created
Starting Samurai Shodown IV - Amakusa's Revenge / Samurai Spirits - Amakusa Kour
in (NGM-222)(NGH-222) ':'
Optional device 'cartslot6' not found
Optional device 'cartslot5' not found
Optional device 'cartslot4' not found
Optional device 'cartslot3' not found
Optional device 'cartslot2' not found
Optional device 'cartslot1' not found
(missing dependencies; rescheduling)
Starting M68000 ':maincpu'
Starting Z80 ':audiocpu'
Starting Video Screen ':screen'
Optional device 'finder_dummy_tag' not found
Starting palette ':palette'
Starting Neogeo Sprites ':spritegen'
Starting Speaker ':lspeaker'
(missing dependencies; rescheduling)
Starting Speaker ':rspeaker'
(missing dependencies; rescheduling)
Starting YM2610 ':ymsnd'
Starting NeoGeo Banked Cartridge ':banked_cart'
Starting uPD4990A RTC ':upd4990a'
Starting NVRAM ':saveram'
Starting NeoGeo Memory Card ':memcard'
Starting NeoGeo Protection (Metal Slug X) ':mslugx_prot'
Starting NeoGeo SMA Cartridge ':sma_prot'
Starting NeoGeo Protection (CMC) ':cmc_prot'
Starting NeoGeo Protection (NEOPCM2) ':pcm2_prot'
Starting NeoGeo Protection (PVC) ':pvc_prot'
Starting NeoGeo Protection (Bootleg) ':bootleg_prot'
Starting NeoGeo Protection (KOF2002) ':kof2002_prot'
Starting NeoGeo Protection (Fatal Fury 2) ':fatfury2_prot'
Starting NeoGeo Protection (KOF98) ':kof98_prot'
Starting NeoGeo Protection (Super Bubble Pop) ':sbp_prot'
Starting Samurai Shodown IV - Amakusa's Revenge / Samurai Spirits - Amakusa Kour
in (NGM-222)(NGH-222) ':'
Optional device 'cartslot6' not found
Optional device 'cartslot5' not found
Optional device 'cartslot4' not found
Optional device 'cartslot3' not found
Optional device 'cartslot2' not found
Optional device 'cartslot1' not found
(missing dependencies; rescheduling)
Starting Speaker ':lspeaker'
Starting Speaker ':rspeaker'
Starting Samurai Shodown IV - Amakusa's Revenge / Samurai Spirits - Amakusa Kour
in (NGM-222)(NGH-222) ':'
Optional device 'cartslot6' not found
Optional device 'cartslot5' not found
Optional device 'cartslot4' not found
Optional device 'cartslot3' not found
Optional device 'cartslot2' not found
Optional device 'cartslot1' not found
Loading cheats file from cheat
ASIO: Advancing head 523 counts at update 2, speed is 1.000000
ASIO: Advancing head 116 counts at update 7, speed is 1.000000
ASIO: Advancing head 116 counts at update 16, speed is 1.013823
ASIO: Advancing head 112 counts at update 25, speed is 1.013823
ASIO: Advancing head 113 counts at update 34, speed is 1.013765
ASIO: Advancing head 112 counts at update 43, speed is 1.013765
Average speed: 101.37% (517 seconds)
ASIO: Average callback timeslice usage: 0.174222
ASIO: Overrun/underrun: 0/0
window_proc: WM_NCACTIVATE
blit_lock = TRUE
window_proc: WM_DESTROY
blit_lock = TRUE
Blitting thread destroyed
-
Thanks for posting! That's a picture perfect result.
-
Just wanted to give a bit of an update. After a while i noticed that the official sb drivers won't take exclusive control when asio is used, which led me to believe that something's wrong with them.
So i decided, for the last time, to install the kX drivers. Apparently, they also don't take exclusive control. Furthermore, i can't use winamp with maiko wasapi plugin (Uses exclusive wasapi mode) with them, keeps getting errors, so there's a chance that there is a problem with wasapi/exclusive mode with these drivers. Can you test that, intealls?
Other than that, i decided to give 64 samples another go, and good thing i did.
It seems that when i start a game from hyperspin there are crackles and pops for a few seconds, but it sorts itself out. Setting the priority to 1 in the ini seems to help a bit, but it's hard to determine that. I believe this happens due to the fact it doesn't take exclusive control of the audio. I should also mention that when starting a game outside hyperspin things seem to be better, with the audio being crackles and pop free for the most part. Only sometimes it starts with some crackles and pops ,but for a second or so, so it's not a big deal.
So that's that for now.
Also, i wanted to ask, what does the audio_latency setting do? I've read in one of your posts that it sets the intermediary buffer(?).
Should i set it to anything other than 1?
-
Just wanted to give a bit of an update. After a while i noticed that the official sb drivers won't take exclusive control when asio is used, which led me to believe that something's wrong with them.
So HS does not work properly with the official drivers?
So i decided, for the last time, to install the kX drivers. Apparently, they also don't take exclusive control. Furthermore, i can't use winamp with maiko wasapi plugin (Uses exclusive wasapi mode) with them, keeps getting errors, so there's a chance that there is a problem with wasapi/exclusive mode with these drivers. Can you test that, intealls?
How does this manifest itself? I'll try HS with kX (Live!) and Winamp with the maiko plugin.
Edit: Just tested maiko, and couldn't get it to work with any of the sound cards in my test box, neither kX, Realtek official drivers nor Xonar DGX (tried both exclusive and shared mode). Used Winamp 5.666 Lite with the maiko from here: http://maiko.elementfx.com (http://maiko.elementfx.com) and Winamp from here: http://meggamusic.co.uk/winamp/Winamp_Download.htm (http://meggamusic.co.uk/winamp/Winamp_Download.htm.).
Other than that, i decided to give 64 samples another go, and good thing i did.
It seems that when i start a game from hyperspin there are crackles and pops for a few seconds, but it sorts itself out. Setting the priority to 1 in the ini seems to help a bit, but it's hard to determine that. I believe this happens due to the fact it doesn't take exclusive control of the audio. I should also mention that when starting a game outside hyperspin things seem to be better, with the audio being crackles and pop free for the most part. Only sometimes it starts with some crackles and pops ,but for a second or so, so it's not a big deal.
So that's that for now.
Yes, this is unfortunately the case with realtime audio (and sometimes misbehaving drivers). If you have stuff chugging in the background (which HS probably has), it is very likely to affect the real time process. Try setting 'sleep 0' in the ini, along with 'priority 1'. Also try increasing the ASIO buffer size to 128, if these changes don't improve the situation, increase the audio_latency to 2 (with 128 buffer size). Are you using a static frame_delay setting or similar? Also, if possible, could you post a log of a misbehaving game? It might be tricky to do this if launched from HS.
ASIO is unfortunately tricky sometimes - the quality of the drivers can vary astronomically between cards and other issues which are not exhibited when not using it come to light. But when it works right (also in combination with frame_delay) it's pretty magical.
-
So HS does not work properly with the official drivers?
It works just fine, i just meant that i was under the assumption that for asio to work properly with low latency it needs to take exclusive control, which it didn't. That's why i thought something is wrong.
Edit: Just tested maiko, and couldn't get it to work with any of the sound cards in my test box, neither kX, Realtek official drivers nor Xonar DGX (tried both exclusive and shared mode). Used Winamp 5.666 Lite with the maiko from here: http://maiko.elementfx.com (http://maiko.elementfx.com) and Winamp from here: http://meggamusic.co.uk/winamp/Winamp_Download.htm (http://meggamusic.co.uk/winamp/Winamp_Download.htm.).
Definitely weird, it works just fine when used with the official sb drivers,the d2x and the nvidia hdmi audio, though haven't tested it with the realtek.
Yes, this is unfortunately the case with realtime audio (and sometimes misbehaving drivers). If you have stuff chugging in the background (which HS probably has), it is very likely to affect the real time process. Try setting 'sleep 0' in the ini, along with 'priority 1'. Also try increasing the ASIO buffer size to 128, if these changes don't improve the situation, increase the audio_latency to 2 (with 128 buffer size). Are you using a static frame_delay setting or similar? Also, if possible, could you post a log of a misbehaving game? It might be tricky to do this if launched from HS.
Sleep and priority are already set, by asio buffer size do you mean change the samples on the asio control panel? if so, i can already tell you that 96 samples fixes the issue, just like the official sb drivers, but i just wanted to try and get 64 samples working properly. About the audio_latency, can you please explain that option? What exactly does it do and what possible options does it have?
I am using a frame delay of 7 in general, but i also tried with 0 and unfortunately there are still crackles and pops.
The thing is that it only happens at the start of a game, in the very few first seconds, and even then it doesn't always happen, pretty random.
-
So HS does not work properly with the official drivers?
It works just fine, i just meant that i was under the assumption that for asio to work properly with low latency it needs to take exclusive control, which it didn't. That's why i thought something is wrong.
Nope, as long as you're getting audio you're set.
Sleep and priority are already set, by asio buffer size do you mean change the samples on the asio control panel? if so, i can already tell you that 96 samples fixes the issue, just like the official sb drivers, but i just wanted to try and get 64 samples working properly. About the audio_latency, can you please explain that option? What exactly does it do and what possible options does it have?
I am using a frame delay of 7 in general, but i also tried with 0 and unfortunately there are still crackles and pops.
The thing is that it only happens at the start of a game, in the very few first seconds, and even then it doesn't always happen, pretty random.
Yup, at the control panel. The audio_latency setting controls how many ASIO buffer-sized chunks to keep in the intermediary buffer between MAME and BASSASIO. If you use a setting of 2, it will try to keep 3 chunks in the buffer. If you use an audio_latency setting of 1, it will attempt to keep 2 chunks in the buffer. As such, when you use a latency setting of 96 with audio_latency 1, the total latency will be about 6 ms. If you use a buffer size of 64, the total latency will be about 4 ms. This allows for some leniency between MAME and BASSASIO. Setting it too strict will greatly reduce playback quality, since the slightest deviation in timing will cause the buffer to underrun. A too relaxed setting will cause higher latency than needed. I settled on these values since they appeared to work well in most scenarios. For your setup, the end result is that it's much better to leave audio_latency at 1 and try to solve any issues by increasing the ASIO buffer size.
Also, I treat the audio latency parameter as an integer currently, I should probably change it to a float to allow for more control, you could try setting it to 0.1 which will round it down to 0 for the absolute strictest setting (64 samples ASIO, audio_latency 0.1 should give about 2.66 ms of total latency), and see if that works, a lot of changes have been done so it might work better now than last time I tried it. But for games with varying frame times it will probably cause problems.
If you're only getting pops and crackles the very first second or so, my suspicion is that MAME very often hasn't been "properly started" yet. Subsystems and the operating system are still catching up. This will lead to an emulation speed that is not at 100% (which is verified by the log created by the ASIO implementation), and as such the audio buffers are not being fed as they should, which leads to the pops and crackles. The over-/underrun counter disregards the first few seconds of game time, so this is the preferred method of verifying that the setup works correctly. My guess is that it might be difficult to solve in a good way, and since it only affects the first second or so I haven't bothered too much with it.
-
Just tried audio_latency 0.1 with 4 games and it works exactly like audio_latency set to 1, crackles and pops for a few seconds and then works perfectly.
Of course if i set the buffer size to 96 everything is fine.
Honestly, this is more than ok by me, i'm getting an insanely low audio latency with just a few crackles at start, really not a big deal.
As far as i see it, everything's fine and we can consider this as solved.
Thank you for all your help.
-
Just tried audio_latency 0.1 with 4 games and it works exactly like audio_latency set to 1, crackles and pops for a few seconds and then works perfectly.
Of course if i set the buffer size to 96 everything is fine.
Great, I might want to try this out, what game(s) and driver are you verifying this with? Is it the official SB driver or kX?
-
Just tried audio_latency 0.1 with 4 games and it works exactly like audio_latency set to 1, crackles and pops for a few seconds and then works perfectly.
Of course if i set the buffer size to 96 everything is fine.
Great, I might want to try this out, what game(s) and driver are you verifying this with? Is it the official SB driver or kX?
I tried Ninja masters, Street fighter Alpha Warrior's dream and Bad dudes vs dragon ninja.
I also use mame as my console emulator, so i tried comix zone too.
kX Driver.
-
Just tried audio_latency 0.1 with 4 games and it works exactly like audio_latency set to 1, crackles and pops for a few seconds and then works perfectly.
Of course if i set the buffer size to 96 everything is fine.
Great, I might want to try this out, what game(s) and driver are you verifying this with? Is it the official SB driver or kX?
I tried Ninja masters, Street fighter Alpha Warrior's dream and Bad dudes vs dragon ninja.
I also use mame as my console emulator, so i tried comix zone too.
kX Driver.
Sorry for the double comment, Pressed quote instead of modify by accident.
-
Ok, thanks for reporting!
-
One last update. Tried the d2x with 1ms (48 samples) and audio_latency set to 0.1 and it's working perfectly.
-
One last update. Tried the d2x with 1ms (48 samples) and audio_latency set to 0.1 and it's working perfectly.
That's actually pretty awesome :) - I might need to look over the audio_latency setting for the next release. How fast is the PC you're using?
-
The emulation pc with the d2x is actually isn't that fast. It's a quad core q8200 oc'ed to 2.9Ghz.
The one with the audigy 4, with the kx drivers, is in fact the faster one, I5-4570 3.2Ghz, and that's the one with the crackles, lol.
-
One last update. Tried the d2x with 1ms (48 samples) and audio_latency set to 0.1 and it's working perfectly.
That's actually pretty awesome :) - I might need to look over the audio_latency setting for the next release. How fast is the PC you're using?
I just wanted to say thanks for this ASIO build. It works great here with Realtek. I have a jesting though. Why do you say that LCDS need to enable multithreading? It works fine here without it.
Also, will you please release an ASIO diff that isn'the based on GroovyMAME?
I hacked together a build that doesn't have any of the switchres stuff, but who knows if I did anything wrong.
-
Hi Roberto,
The multithreading option in GroovyMAME has a different implementation from baseline MAME. The way it's implemented has a double aim: improve input response and make asynchronous triple buffering possible (when required). The reason intealls is recommending it is to provide the best performance with regards to the combination on input, video, and audio latency, assuming the whole GroovyMAME implementation is available. If you only apply the ASIO diff, then probably it's best not to use multithreading which is known to be problematic in baseline.
By the way, do you think there's any chance that intealls' ASIO implementation could make into the official project?
-
By the way, do you think there's any chance that intealls' ASIO implementation could make into the official project?
I think this will be problematic due to the use of BASSASIO. But there are bits and pieces that in one form or another perhaps could make it into mainline, possibly the calibration frequency stuff and the audio update at end-of-frame etc. But currently it's probably best to view it as a recipe for low latency audio in MAME. :)
I just wanted to say thanks for this ASIO build. It works great here with Realtek. I have a jesting though. Why do you say that LCDS need to enable multithreading? It works fine here without it.
Also, will you please release an ASIO diff that isn'the based on GroovyMAME?
I hacked together a build that doesn't have any of the switchres stuff, but who knows if I did anything wrong.
Thanks! Sure, I'll fix one up later tonight.
The multithreading option in GroovyMAME has a different implementation from baseline MAME. The way it's implemented has a double aim: improve input response and make asynchronous triple buffering possible (when required). The reason intealls is recommending it is to provide the best performance with regards to the combination on input, video, and audio latency, assuming the whole GroovyMAME implementation is available. If you only apply the ASIO diff, then probably it's best not to use multithreading which is known to be problematic in baseline.
Absolutely, also, GM really does make things shine. Currently the absolutely closest one gets to the real thing is GM on CRT + ASIO + frame delay. Configuring ASIO and frame delay is still a bit tricky though.
-
Here's the patch for mainline, some minor changes needed to be done since GM handles game speed a bit differently.
Just like Calamity states, multithreading should not be used when run on mainline.
Also, thank you (and the rest of MAMEDEV!) for MAME! It really is an amazing project.
-
Hi
I've read about the frame delay benchmark in the OP but need it explaining a bit more, please. For example, I ran 'mame64 pacman -bench 10 > log.txt', and the log states:
frame delay/percentage: 8/100.00%
Average speed: 13005.98% (9 seconds)
So, this means I should use a frame delay of 8 for Pac-Man? I know percentage refers to "percentage of frame time", but don't really understand what that means.
Thanks.
-
Hi
I've read about the frame delay benchmark in the OP but need it explaining a bit more, please. For example, I ran 'mame64 pacman -bench 10 > log.txt', and the log states:
frame delay/percentage: 8/100.00%
Average speed: 13005.98% (9 seconds)
So, this means I should use a frame delay of 8 for Pac-Man? I know percentage refers to "percentage of frame time", but don't really understand what that means.
Thanks.
Hi,
Yes, as long as you're not using vsync_offset and syncrefresh is being used you could use a setting of 8.
-
Hi
I've read about the frame delay benchmark in the OP but need it explaining a bit more, please. For example, I ran 'mame64 pacman -bench 10 > log.txt', and the log states:
frame delay/percentage: 8/100.00%
Average speed: 13005.98% (9 seconds)
So, this means I should use a frame delay of 8 for Pac-Man? I know percentage refers to "percentage of frame time", but don't really understand what that means.
Thanks.
Hi,
Yes, as long as you're not using vsync_offset and syncrefresh is being used you could use a setting of 8.
I don't use vsync_offset at the moment, so that's OK. GM itself decides whether to use syncrefresh or not, doesn't it? If syncrefresh doesn't get used, should I just set frame delay to 0, for that game?
-
I don't use vsync_offset at the moment, so that's OK. GM itself decides whether to use syncrefresh or not, doesn't it? If syncrefresh doesn't get used, should I just set frame delay to 0, for that game?
If SwitchRes automatically controls the use of syncrefresh (which is definitely the preferred way of controlling syncrefresh), the frame_delay setting will not be used for games that do not use it. So even if you set frame_delay 8, if syncrefresh isn't used for the game, it will not use frame_delay at all.
-
I don't use vsync_offset at the moment, so that's OK. GM itself decides whether to use syncrefresh or not, doesn't it? If syncrefresh doesn't get used, should I just set frame delay to 0, for that game?
If SwitchRes automatically controls the use of syncrefresh (which is definitely the preferred way of controlling syncrefresh), the frame_delay setting will not be used for games that do not use it. So even if you set frame_delay 8, if syncrefresh isn't used for the game, it will not use frame_delay at all.
Ah, I see. Thanks for clearing that up, for me.
-
Hi intealls,
Thank you very much for your work on this. It looks like a very very interesting project and I'm quite keen to try ASIO out in GM.
I was about to ask if you had diff files available so I could compile my own GM ASIO and I just noticed them at the bottom of the first post. Doh!!!
I happened to have an old Sound Blaster Live! 5.1 lying around, that I forgot I had. I've just plugged it into my cabinet and installed KX Drivers. Very keen on trying this out. Probably try tomorrow.
-
Updated to 0.171, mainline is now supported with a separate patch. Check the build instructions page if building from source, since a slight modification was needed.
-
I just have to say, after tons of testing this is incredible. I have always felt the disconnect in the audio latency was worse than the control lag. Now running this with d3d9ex with frame delay of 5 and I can't tell the difference between my jamma boards. Love it. Thanks for your collective hard work.
-
Thanks! The reason I started developing the ASIO stuff was GM on CRT and frame_delay. Now that the ASIO stuff works well it does come together quite nicely. :)
-
Now on my bartop, it is working excellent as well. However, cannot enable HLSL at all .170 and .171. I haven't been able to confirm if it is this branch or anything but it's driving me bananas. 17" LCD in it. Here is my mame.ini, if you find something off. No errors, just runs with no filters. I refuse to use straight groovy now because of ASIO lol. One thing I noticed if I set refresh_dont_care to 0, switchres will not function at all (so probably why it's suggested on page 1). Thanks again!
ATi HD 3450 using crtemu_driver. Is there any benefit using Calamity's drivers with an LCD?
#
# CORE CONFIGURATION OPTIONS
#
readconfig 1
writeconfig 0
#
# CORE SEARCH PATH OPTIONS
#
rompath roms
hashpath hash
samplepath samples
artpath artwork
ctrlrpath ctrlr
inipath .;ini
fontpath .
cheatpath cheat
crosshairpath crosshair
#
# CORE OUTPUT DIRECTORY OPTIONS
#
cfg_directory cfg
nvram_directory nvram
input_directory inp
state_directory sta
snapshot_directory snap
diff_directory diff
comment_directory comments
#
# CORE OUTPUT DIRECTORY OPTIONS
#
hiscore_directory hi
#
# CORE STATE/PLAYBACK OPTIONS
#
state
autosave 0
playback
record
mngwrite
aviwrite
wavwrite
snapname %g/%i
snapsize auto
snapview internal
snapbilinear 1
statename %g
burnin 0
#
# CORE PERFORMANCE OPTIONS
#
autoframeskip 0
frameskip 0
seconds_to_run 0
throttle 1
syncrefresh 0
sleep 0
speed 1.0
refreshspeed 0
#
# CORE ROTATION OPTIONS
#
rotate 1
ror 0
rol 0
autoror 0
autorol 0
flipx 0
flipy 0
#
# CORE ARTWORK OPTIONS
#
artwork_crop 1
use_backdrops 0
use_overlays 0
use_bezels 0
use_cpanels 0
use_marquees 0
#
# CORE SCREEN OPTIONS
#
brightness 1.0
contrast 1.0
gamma 1.0
pause_brightness 0.65
effect none
#
# CORE VECTOR OPTIONS
#
antialias 1
beam_width_min 1.0
beam_width_max 1.0
beam_intensity_weight 0
flicker 0
#
# CORE SOUND OPTIONS
#
samplerate 48000
samples 1
volume 0
#
# CORE INPUT OPTIONS
#
coin_lockout 1
ctrlr
mouse 0
joystick 1
lightgun 0
multikeyboard 0
multimouse 0
steadykey 0
ui_active 0
offscreen_reload 0
joystick_map auto
joystick_deadzone 0.3
joystick_saturation 0.85
natural 0
joystick_contradictory 0
coin_impulse 0
#
# CORE INPUT AUTOMATIC ENABLE OPTIONS
#
paddle_device keyboard
adstick_device keyboard
pedal_device keyboard
dial_device keyboard
trackball_device keyboard
lightgun_device keyboard
positional_device keyboard
mouse_device mouse
#
# CORE DEBUGGING OPTIONS
#
verbose 0
log 0
oslog 0
debug 0
update_in_pause 0
debugscript
#
# CORE COMM OPTIONS
#
comm_localhost 0.0.0.0
comm_localport 15112
comm_remotehost 127.0.0.1
comm_remoteport 15112
#
# CORE MISC OPTIONS
#
drc 1
drc_use_c 0
drc_log_uml 0
drc_log_native 0
bios
cheat 0
skip_gameinfo 0
uifont default
ramsize
confirm_quit 0
ui_mouse 0
autoboot_command
autoboot_delay 2
autoboot_script
console 0
#
# CORE MKChamp OPTIONS
#
disable_hiscore_patch 0
disable_nagscreen_patch 0
disable_loading_patch 0
#
# CORE SWITCHRES OPTIONS
#
modeline_generation 1
monitor lcd
orientation vertical
connector auto
interlace 1
doublescan 1
cleanstretch 1
changeres 1
powerstrip 0
lock_system_modes 1
lock_unsupported_modes 1
refresh_dont_care 1
dotclock_min 0
sync_refresh_tolerance 2.0
frame_delay 0
vsync_offset 0
black_frame_insertion 0
modeline auto
ps_timing auto
lcd_range 50-60
crt_range0 auto
crt_range1 auto
crt_range2 auto
crt_range3 auto
crt_range4 auto
crt_range5 auto
crt_range6 auto
crt_range7 auto
crt_range8 auto
crt_range9 auto
asio_log 0
asio_device 0
asio_cal_freq 0.0
#
# OSD KEYBOARD MAPPING OPTIONS
#
uimodekey SCRLOCK
#
# OSD FONT OPTIONS
#
uifontprovider auto
#
# OSD DEBUGGING OPTIONS
#
debugger auto
debugger_font auto
debugger_font_size 0
watchdog 0
#
# OSD PERFORMANCE OPTIONS
#
multithreading 1
numprocessors auto
bench 0
#
# OSD VIDEO OPTIONS
#
video d3d9ex
numscreens 1
window 0
maximize 1
keepaspect 0
unevenstretch 0
waitvsync 0
#
# OSD PER-WINDOW VIDEO OPTIONS
#
screen auto
aspect 5:4
resolution 1280x1024@0
view auto
screen0 auto
aspect0 auto
resolution0 auto
view0 auto
screen1 auto
aspect1 auto
resolution1 auto
view1 auto
screen2 auto
aspect2 auto
resolution2 auto
view2 auto
screen3 auto
aspect3 auto
resolution3 auto
view3 auto
#
# OSD FULL SCREEN OPTIONS
#
switchres 1
#
# OSD ACCELERATED VIDEO OPTIONS
#
filter 0
prescale 1
#
# OpenGL-SPECIFIC OPTIONS
#
gl_forcepow2texture 0
gl_notexturerect 0
gl_vbo 1
gl_pbo 1
gl_glsl 0
gl_glsl_filter 1
glsl_shader_mame0 none
glsl_shader_mame1 none
glsl_shader_mame2 none
glsl_shader_mame3 none
glsl_shader_mame4 none
glsl_shader_mame5 none
glsl_shader_mame6 none
glsl_shader_mame7 none
glsl_shader_mame8 none
glsl_shader_mame9 none
glsl_shader_screen0 none
glsl_shader_screen1 none
glsl_shader_screen2 none
glsl_shader_screen3 none
glsl_shader_screen4 none
glsl_shader_screen5 none
glsl_shader_screen6 none
glsl_shader_screen7 none
glsl_shader_screen8 none
glsl_shader_screen9 none
#
# OSD SOUND OPTIONS
#
sound auto
audio_latency 0.1
#
# WINDOWS PERFORMANCE OPTIONS
#
priority 0
profile 0
#
# WINDOWS VIDEO OPTIONS
#
menu 0
#
# DIRECTDRAW-SPECIFIC OPTIONS
#
hwstretch 0
#
# DIRECT3D POST-PROCESSING OPTIONS
#
hlsl_enable 1
hlslpath hlsl
hlsl_prescale_x 6
hlsl_prescale_y 6
hlsl_write 1
hlsl_snap_width 1280
hlsl_snap_height 1024
shadow_mask_tile_mode 0
shadow_mask_alpha 0.15
shadow_mask_texture slot-mask.png
shadow_mask_x_count 6
shadow_mask_y_count 4
shadow_mask_usize 0.1875
shadow_mask_vsize 0.1875
shadow_mask_uoffset 0.0
shadow_mask_voffset 0.0
curvature 0.10
round_corner 0.10
smooth_border 0.03
reflection 0.0
vignetting 0.20
scanline_alpha 1.50
scanline_size 1.0
scanline_height 1.0
scanline_bright_scale 1.15
scanline_bright_offset 0.0
scanline_jitter 0.1
hum_bar_alpha 0.0
defocus 0.20,0.0
converge_x 0.25,0.00,-0.25
converge_y 0.0,0.25,-0.25
radial_converge_x 0.0,0.0,0.0
radial_converge_y 0.0,0.0,0.0
red_ratio 1.0,0.0,0.0
grn_ratio 0.0,1.0,0.0
blu_ratio 0.0,0.0,1.0
saturation 1.4
offset 0.0,0.0,0.0
scale 0.95,0.95,0.95
power 0.8,0.8,0.8
floor 0.01,0.01,0.01
phosphor_life 0.4,0.4,0.4
#
# NTSC POST-PROCESSING OPTIONS
#
yiq_enable 0
yiq_jitter 0.0
yiq_cc 3.57954545
yiq_a 0.5
yiq_b 0.5
yiq_o 0.0
yiq_p 1.0
yiq_n 1.0
yiq_y 6.0
yiq_i 1.2
yiq_q 0.6
yiq_scan_time 52.6
yiq_phase_count 2
#
# VECTOR POST-PROCESSING OPTIONS
#
vector_length_scale 0.5
vector_length_ratio 500.0
#
# BLOOM POST-PROCESSING OPTIONS
bloom_blend_mode 0
bloom_scale 0.28
bloom_overdrive 1.0,1.0,1.0
bloom_lvl0_weight 1.0
bloom_lvl1_weight 0.64
bloom_lvl2_weight 0.32
bloom_lvl3_weight 0.16
bloom_lvl4_weight 0.08
bloom_lvl5_weight 0.04
bloom_lvl6_weight 0.04
bloom_lvl7_weight 0.02
bloom_lvl8_weight 0.02
bloom_lvl9_weight 0.01
bloom_lvl10_weight 0.01
#
# FULL SCREEN OPTIONS
#
triplebuffer 0
full_screen_brightness 1.0
full_screen_contrast 1.0
full_screen_gamma 1.0
#
# INPUT DEVICE OPTIONS
#
global_inputs 0
dual_lightgun 0
-
Strange, have you downloaded the standard MAME package, and overwritten the executable with the GMASIO one?
With the version in GIT, I wasn't able to get HLSL working until the artwork path was set up correctly.
-
Yeah. :/
Just did it again from scratch. Textbook. Even updated dx11.1 and re-installed the dx9 redistributable. No go. Really bums me out. I know the system is capable of it. No idea why it won't work. GLSL worked fine.
For giggles - my verbose log. Forced 640x480 just to try to get a low res option working since 1280x1024 didn't work.
**Last update - Did mame.exe pacman -hlsl. Worked with default garbage settings. Looked like hot poop. So there has to be something in my INI breaking something, or its just not reading it right.
C:\mame>mame.exe pacman -v
SwitchRes: v0.015m, Monitor: lcd, Orientation: vertical, Modeline generation: en
abled
SwitchRes: LCD vfreq range set by user as 50.000000-60.000000
SwitchRes: \\.\DISPLAY1: ATI Radeon HD 3470 (CRT Emudriver - WDDM v1.1) (PCI\VEN
_1002&DEV_95C0&SUBSYS_0B421002&REV_00)
SwitchRes: Device key: System\CurrentControlSet\Control\Video\{071692DE-FF3F-4DA
A-9D3B-81CA90906D04}\0000
ATI legacy init
Switchres: Searching for custom video modes...
Switchres: [ 1] 640x 480 @ 59 : system mode
Switchres: [ 2] 640x 480 @ 60* : system mode
Switchres: [ 3] 640x 480 @ 72 : system mode
Switchres: [ 4] 640x 480 @ 75 : system mode
Switchres: [ 5] 720x 480 @ 60 : system mode
Switchres: [ 6] 800x 600 @ 56 : system mode
Switchres: [ 7] 800x 600 @ 60 : system mode
Switchres: [ 8] 800x 600 @ 70 : system mode
Switchres: [ 9] 800x 600 @ 72 : system mode
Switchres: [ 10] 800x 600 @ 75 : system mode
Switchres: [ 11] 1024x 768 @ 60 : system mode
Switchres: [ 12] 1024x 768 @ 70 : system mode
Switchres: [ 13] 1024x 768 @ 72 : system mode
Switchres: [ 14] 1024x 768 @ 75 : system mode
Switchres: [ 15] 1152x 864 @ 60 : system mode
Switchres: [ 16] 1152x 864 @ 70 : system mode
Switchres: [ 17] 1152x 864 @ 75 : system mode
Switchres: [ 18] 1280x 720 @ 59 : system mode
Switchres: [ 19] 1280x 720 @ 60 : system mode
Switchres: [ 20] 1280x 768 @ 56 : system mode
Switchres: [ 21] 1280x 768 @ 60 : system mode
Switchres: [ 22] 1280x 768 @ 75 : system mode
Switchres: [ 23] 1280x 800 @ 60 : system mode
Switchres: [ 24] 1280x 800 @ 75 : system mode
Switchres: [ 25] 1280x 960 @ 60 : system mode
Switchres: [ 26] 1280x 960 @ 70 : system mode
Switchres: [ 27] 1280x 960 @ 72 : system mode
Switchres: [ 28] 1280x 960 @ 75 : system mode
Switchres: [ 29] 1280x1024 @ 60 : system mode
Switchres: [ 30] 1280x1024 @ 70 : system mode
Switchres: [ 31] 1280x1024 @ 75 : system mode
SwitchRes: Found 0 custom of 31 active video modes
SwitchRes: Creating automatic specs for LCD based on VESA GTF
SwitchRes: Monitor range 24850.00-29820.00,50.00-60.00,0.671,2.683,3.353,0.034,0
.101,0.436,0,1,480,480,0,0
SwitchRes: -resolution was forced as 640x480@60
SwitchRes: Entering switchres_modeline_setup
SwitchRes: v0.015m:[pacman] Calculating best video mode for 288x224@60.606060 or
ientation: normal
SwitchRes: [ 640]x[ 480]_(59=59.000000Hz) - locked
SwitchRes: [ 640]x[ 480]_(60=60.000000Hz)
rng(0): 640 x 480_60.000000p 29.820000 [fract] scale(2, 2, 1) diff(10.00, 13
.08, -0.6061) ratio(2.222, 2.143)
SwitchRes: [ 640]x[ 480]_(72=72.000000Hz) - locked
SwitchRes: [ 640]x[ 480]_(75=75.000000Hz) - locked
SwitchRes: [ 720]x[ 480]_(60=60.000000Hz) - locked
SwitchRes: [ 800]x[ 600]_(56=56.000000Hz) - locked
SwitchRes: [ 800]x[ 600]_(60=60.000000Hz) - locked
SwitchRes: [ 800]x[ 600]_(70=70.000000Hz) - locked
SwitchRes: [ 800]x[ 600]_(72=72.000000Hz) - locked
SwitchRes: [ 800]x[ 600]_(75=75.000000Hz) - locked
SwitchRes: [1024]x[ 768]_(60=60.000000Hz) - locked
SwitchRes: [1024]x[ 768]_(70=70.000000Hz) - locked
SwitchRes: [1024]x[ 768]_(72=72.000000Hz) - locked
SwitchRes: [1024]x[ 768]_(75=75.000000Hz) - locked
SwitchRes: [1152]x[ 864]_(60=60.000000Hz) - locked
SwitchRes: [1152]x[ 864]_(70=70.000000Hz) - locked
SwitchRes: [1152]x[ 864]_(75=75.000000Hz) - locked
SwitchRes: [1280]x[ 720]_(59=59.000000Hz) - locked
SwitchRes: [1280]x[ 720]_(60=60.000000Hz) - locked
SwitchRes: [1280]x[ 768]_(56=56.000000Hz) - locked
SwitchRes: [1280]x[ 768]_(60=60.000000Hz) - locked
SwitchRes: [1280]x[ 768]_(75=75.000000Hz) - locked
SwitchRes: [1280]x[ 800]_(60=60.000000Hz) - locked
SwitchRes: [1280]x[ 800]_(75=75.000000Hz) - locked
SwitchRes: [1280]x[ 960]_(60=60.000000Hz) - locked
SwitchRes: [1280]x[ 960]_(70=70.000000Hz) - locked
SwitchRes: [1280]x[ 960]_(72=72.000000Hz) - locked
SwitchRes: [1280]x[ 960]_(75=75.000000Hz) - locked
SwitchRes: [1280]x[1024]_(60=60.000000Hz) - locked
SwitchRes: [1280]x[1024]_(70=70.000000Hz) - locked
SwitchRes: [1280]x[1024]_(75=75.000000Hz) - locked
SwitchRes: [pacman] (1) horizontal (288x224@60.606060)->(640x480@60.000000)
rng(0): 640 x 480_60.000000p 29.820000 [fract] scale(2, 2, 1) diff(10.00, 13
.08, -0.6061) ratio(2.222, 2.143)
SwitchRes: Modeline "640x480_60 29.820000KHz 60.000000Hz" 23.856000 640 656 720
800 480 481 484 497 -hsync +vsync
Switchres: saving system mode
Switchres: updating Failed saving registry entry DALDTMCRTBCD640x480x0x60
SwitchRes: Setting option -rotate
SwitchRes: Setting option -noror
SwitchRes: Setting option -autoror
SwitchRes: Setting option -norol
SwitchRes: Setting option -noautorol
SwitchRes: Setting option -noblack_frame_insertion
SwitchRes: Setting option -multithreading
SwitchRes: Setting option -notriplebuffer
SwitchRes: Setting option -syncrefresh
SwitchRes: Setting option -waitvsync
SwitchRes: Setting option -keepaspect
SwitchRes: Setting option -filter
SwitchRes: Setting option -prescale 2
Video: Monitor 000000000034A248 = "\\.\DISPLAY1" (primary)
Direct3D: Using Direct3D 9Ex
window_proc: WM_NCACTIVATE
blit_lock = TRUE
Physical width 640, height 480
Direct3D: Configuring adapter #0 = ATI Radeon HD 3470 (CRT Emudriver - WDDM v1.1
)
Direct3D: Adapter has Vendor ID: 1002 and Device ID: 95C0
Direct3D: Using dynamic textures
Direct3D: Using StretchRect for prescaling
Direct3D: YUV format = RGB
Direct3D: Max texture size = 8192x8192
Direct3D: Device created at 640x480
Direct3D: First scanline: 16, Last scanline: 496, Break scanline: 496, Delay sca
nline: -33
blit_unlock = TRUE
window_proc: WM_PAINT
Blitting thread created
winwindow_video_window_create: blit_lock = TRUE
RawInput: APIs detected
Blitting thread started
Input: Adding Mouse #0: HID-compliant mouse
Input: Adding Gun #0: HID-compliant mouse
Input: Adding Kbd #0: HID Keyboard Device
DirectInput: Using DirectInput 8
blit_lock = FALSE
window_proc: WM_PAINT:END
ASIO: Game is running at 60.606060 Hz, screen at about 60.000000 Hz
ASIO: Driver ASIO4ALL v2 initialized with latency 64,
sample rate 48000.00
audio latency is 0
frame delay is 0
ASIO: Setting initial playback rate to 48000.000 Hz
Region ':maincpu' created
Region ':gfx1' created
Region ':proms' created
Region ':namco' created
Starting Pac-Man (Midway) ':'
Optional shared pointer 'patched_opcodes' not found
Optional shared pointer 'rocktrv2_prot' not found
Optional shared pointer 's2650_tileram' not found
Optional shared pointer 's2650_spriteram' not found
(missing dependencies; rescheduling)
Starting Z80 ':maincpu'
Starting gfxdecode ':gfxdecode'
Starting palette ':palette'
Starting Video Screen ':screen'
Starting Speaker ':mono'
(missing dependencies; rescheduling)
Starting Namco ':namco'
Starting Pac-Man (Midway) ':'
Optional shared pointer 'patched_opcodes' not found
Optional shared pointer 'rocktrv2_prot' not found
Optional shared pointer 's2650_tileram' not found
Optional shared pointer 's2650_spriteram' not found
(missing dependencies; rescheduling)
Starting Speaker ':mono'
Starting Pac-Man (Midway) ':'
Optional shared pointer 'patched_opcodes' not found
Optional shared pointer 'rocktrv2_prot' not found
Optional shared pointer 's2650_tileram' not found
Optional shared pointer 's2650_spriteram' not found
Command.dat games found = 145
Average speed: 98.91% (18 seconds)
Switchres: restoring Failed saving registry entry DALDTMCRTBCD640x480x0x60
ASIO: Average callback timeslice usage: 0.487205
ASIO: Overrun/underrun: 0/1
window_proc: WM_NCACTIVATE
blit_lock = TRUE
window_proc: WM_DESTROY
blit_lock = TRUE
Blitting thread destroyed
C:\mame>
-
This is really strange.
I downloaded official MAME 0.171, and extracted the GMASIO executable over the old one. I used your ini, and HLSL worked. This was with an LCD. I did this from the command line, standing in the active MAME directory (mame64 samsho4). Are you using a front-end to launch GM?
-
Ok. I started the ini from straight scratch and worked my way through it. I have no idea what was making it *not* work, but now it is working. I have settings I *like* at 1024x768 @ full speed, but I don't love it. Might throw a few bucks at a HD5450 - this HD3450 is just a bit weak. Plays well, sounds amazing.
Thanks for the help and keep up the great work. With all of the stuff going on with MAME right now, this is my go to version number/branch for some time. Nothing I really need added to it as far as games go, performance is sweet. No noticeable input lag and the sound is dead on. So away we go.
-
What is the recommended/optimal hardware for using this build?
My motherboard has a Realtek ALC887 chip but I'm totally open to purchasing a dedicated sound card if it will give better results (or less hassle to set up/configure).
The only limitation is that it would have to be a PCIe x1 card. This motherboard doesn't have any PCI slots.
-
What is the recommended/optimal hardware for using this build?
My motherboard has a Realtek ALC887 chip but I'm totally open to purchasing a dedicated sound card if it will give better results (or less hassle to set up/configure).
The only limitation is that it would have to be a PCIe x1 card. This motherboard doesn't have any PCI slots.
It mainly depends on if you want to use frame_delay or not, if you want to use high frame_delay settings, you're best off with an overclocked G3258, the higher the clock the better. Also, for frame_delay, a relatively fast graphics card is recommended when using super resolutions (I use an HD5770).
If you're happy without frame_delay, and can live without being able to satisfactorily run cv1k games etc, you could get away with a Core 2 Duo, with an older GPU.
I currently recommend ASIO4ALL+Realtek. However, it does not appear to work with some frontends. Regarding PCI express cards with ASIO support, I've only been able to test one, the Xonar DGX, and that performs much worse than the Realtek+ASIO4ALL combo, it also performs worse than an old SB PCI card with the kX driver. I'd like to test the Juli@ XTe, but those cards are ridiculously expensive. Dr.Venom used this and that seemed to work very well.
-
Just to say that this is a very worthwhile addition which substantially improves the Groovymame experience.
The difference is definietly noticable.
In terms of configuration, I am using a new but relatively modestly specced PC (G4400 Pentium CPU, Asus Z170M-Plus mobo, 16GB RAM, Asus HD 5450 1 GB video card, Win 7 x64) and can safely set all the latancy options to the lowest (audio latancy 0.1 in mame.ini and sample size = 64 in asio4all) without any degredation in performance.
Other options I have turned on are multithreading, tripple buffer and waitvsync.
-
Just a note: with the MAME license change, this ASIO build is now illegal to distribute. BASSASIO is not GPL-compatible; someone needs to write an ASIO driver for MAME that doesn't use BASSASIO in order to solve this.
-
Thanks for the heads up, it shouldn't be all that difficult to get rid of BASSASIO. Are there any extended plans to integrate PortAudio? Otherwise I'll start hacking away at a preliminary native ASIO implementation.
Also, am I right in thinking that 0.171 is still legal to distribute?
-
The JUICE library supports ASIO and it's GPL...
https://github.com/julianstorer/JUCE
-
Thanks for the tip, didn't know about JUCE. I've been doing some tests with other libraries, but JUCE seems to be of higher quality.
-
By reading this one would think adding ASIO support in a GPL licensed project is not possible:
http://wiki.audacityteam.org/wiki/ASIO_Audio_Interface (http://wiki.audacityteam.org/wiki/ASIO_Audio_Interface)
The ASIO technology was developed by German company Steinberg and is protected by a licensing agreement which prevents redistribution of its source code.
Audacity, as an open source program licensed under the GPL, is therefore currently unable to support ASIO, despite being ASIO-capable (providing the user's sound device is similarly capable). If ASIO support were distributed in Audacity builds this would either violate Steinberg's licence agreement if the code were included, or conversely would violate Audacity's GPL Licence if the code were withheld.
I think I'm missing something. If the problem is redistributing the ASIO sdk headers with your own GPL project, wouldn't it be possible to just sort of rip off the required prototypes and structs and create your own header?
I find much more appealing the perspective of creating a native implementation, specially now that MAME osd is so modular, rather than resorting to (yet another) library. But perhaps it's just me understimating the task complexity.
-
intealls: PortAudio is planned to be supported, and I have a preliminary MAME output module for it, but it needs help. If you'd like to take it over, hit me (messdrivers at gmail).
Calamity: totally agreed, ASIO's licensing claims to say things that I'm not sure are actually legally possible. So it's at a weird place wrt GPL software.
ETA: The LMMS Project says they do ASIO w/o Steinberg headers, so we might look at what they're doing.
-
By reading this one would think adding ASIO support in a GPL licensed project is not possible:
http://wiki.audacityteam.org/wiki/ASIO_Audio_Interface (http://wiki.audacityteam.org/wiki/ASIO_Audio_Interface)
The ASIO technology was developed by German company Steinberg and is protected by a licensing agreement which prevents redistribution of its source code.
Audacity, as an open source program licensed under the GPL, is therefore currently unable to support ASIO, despite being ASIO-capable (providing the user's sound device is similarly capable). If ASIO support were distributed in Audacity builds this would either violate Steinberg's licence agreement if the code were included, or conversely would violate Audacity's GPL Licence if the code were withheld.
I think I'm missing something. If the problem is redistributing the ASIO sdk headers with your own GPL project, wouldn't it be possible to just sort of rip off the required prototypes and structs and create your own header?
I find much more appealing the perspective of creating a native implementation, specially now that MAME osd is so modular, rather than resorting to (yet another) library. But perhaps it's just me understimating the task complexity.
This is certainly unfortunate. A native WASAPI implementation could be a good, clean solution, but PortAudio offers lots and lots of stuff. We would get ASIO (although the user would need to get the ASIO SDK, build from source and not distribute the binary (http://wiki.audacityteam.org/wiki/ASIO_Audio_Interface#Non-distributable_ASIO_support_in_Audacity)), WASAPI and WDM-KS all rolled into one, which sounds like a fantastic deal. I need to look into if PortAudio will add any latency, and also study it generally. But if I'm able to handle it I'll gladly help out!
The trickiest bit is probably how to deal with the resampling, which is really needed for ASIO to work properly (it could also make other APIs sound better as well). There are two variables that we need to resample the audio correctly, game speed and sound card output frequency. The output frequency is currently estimated through linear regression, and with mainline MAME, game speed is easy since it will (most of the time) be fixed at 100%. With GM+syncrefresh, it will vary a tiny bit, but the speed is available from the video subsystem (m_speed_percent).
MAME resamples the audio, but this resampler does not offer the granularity that we need without resorting to some sort of hack (integer rounding, so one possible solution is to switch between several rates for added resolution). A straight forward solution could be to rewrite the resampler for finer granularity, and also take into account playback frequency and game speed. But I need to look into how the details of this would work out, it could turn out messy. BASSASIO has a built-in resampler, which was used by the ASIO implementation, it simply resampled the audio again in the OSD layer.
-
Agree with Arbee and Calamity. MAME just needs a low-latency API equal to ASIO and Portaudio seems perfect for this, as it includes any OS platform and many different APIs (incl. ASIO).
http://git.redump.net/mame/tree/3rdparty/portaudio/README.txt (http://git.redump.net/mame/tree/3rdparty/portaudio/README.txt)
WASAPI on the other side is windows only and from what i know, it is not easy to program. It came from a Vista time and i dont think it has a good/stable future. It seems that low-latency is bounded with exclusive control over the used sound-card and that there are no(t) many alternatives. Any audio that goes through a OS controled soundcard is simply to slow for this task here.
Reading the license issues here, i am curious how far Portaudio can support ASIO, but the readme states that it supports ASIO ??? .
16.68 milliseconds is the amount of time of 1 frame in a 30FPS game, so in theory we need a low-latency of 16ms.< (emulation time for a frame not included of course) and i think this is not possible without exclusive control over the soundcard.
-
Agree with Arbee and Calamity.
If you read their posts, you can see two different strategies.
MAME just needs a low-latency API equal to ASIO and Portaudio seems perfect for this, as it includes any OS platform and many different APIs (incl. ASIO).
The only API on Windows that has the possibility of being equivalent with ASIO is WASAPI. ALSA is already fairly low latency.
It came from a Vista time and i dont think it has a good/stable future. It seems that low-latency is bounded with exclusive control over the used sound-card and that there are no(t) many alternatives.
DirectSound was introduced with Windows 95. Regarding the alternatives, there is one, which is WASAPI.
Reading the license issues here, i am curious how far Portaudio can support ASIO, but the readme states that it supports ASIO ??? .
Yes, it supports ASIO, but you need add to the ASIO SDK and build from source. MAME cannot be redistributed with ASIO functionality.
16.68 milliseconds is the amount of time of 1 frame in a 30FPS game, so in theory we need a low-latency of 16ms.< (emulation time for a frame not included of course) and i think this is not possible without exclusive control over the soundcard.
No. We need 0 ms latency for frame_delay. And also 1e3/30 = ~33.3.
-
In terms of configuration, I am using a new but relatively modestly specced PC (G4400 Pentium CPU, Asus Z170M-Plus mobo, 16GB RAM, Asus HD 5450 1 GB video card, Win 7 x64) and can safely set all the latancy options to the lowest (audio latancy 0.1 in mame.ini and sample size = 64 in asio4all) without any degredation in performance.
Sorry to interrupt the discussion briefly - just wondered about the audio_latency setting in MAME.INI. I assumed this setting was redundant/unused when using ASIO GM? If not, should I be setting it to 0.1, as above?
-
In terms of configuration, I am using a new but relatively modestly specced PC (G4400 Pentium CPU, Asus Z170M-Plus mobo, 16GB RAM, Asus HD 5450 1 GB video card, Win 7 x64) and can safely set all the latancy options to the lowest (audio latancy 0.1 in mame.ini and sample size = 64 in asio4all) without any degredation in performance.
Sorry to interrupt the discussion briefly - just wondered about the audio_latency setting in MAME.INI. I assumed this setting was redundant/unused when using ASIO GM? If not, should I be setting it to 0.1, as above?
If you aren't getting over-/underruns with 0.1, it should be fine.
-
A native WASAPI implementation could be a good, clean solution
WASAPI would be cool although my suggestion was ASIO without Steinberg's headers, so you could actually distribute the resulting binary. A reverse-engineered asio.h header named "Vestige" is mentioned in many places. However I see the PortAudio approach more feasible.
MAME resamples the audio, but this resampler does not offer the granularity that we need
If the granularity problem is related to the m_speed variable being an integer, I guess this could be easily changed to use a float or any other way that provides an arbitrary degree of accuracy. From the top of my head, m_speed is just used in a couple of places, one being the final sound resampler, so the possibility of breaking something is limited. Although I'm probably missing the issue.
With regards to speed deviations due to dotclock's own granularity with syncrefresh enabled, this might be a minor issue in the future, once a real dotclock look-up table is implemented in Switchres, for those willing to take the time to build the dotclock table for their card and use super resolutions.
-
I may be wrong, but AFAIK, ASIO has less latency than WASAPI. This is just from memory, but I did find this discussion:
http://music.columbia.edu/pipermail/portaudio/2010-June/010357.html (http://music.columbia.edu/pipermail/portaudio/2010-June/010357.html)
And things might have changed since Windows 10 brought improvements to the audio stack:
https://msdn.microsoft.com/en-us/library/windows/hardware/mt298187(v=vs.85).aspx (https://msdn.microsoft.com/en-us/library/windows/hardware/mt298187(v=vs.85).aspx)
-
WASAPI would be cool although my suggestion was ASIO without Steinberg's headers, so you could actually distribute the resulting binary. A reverse-engineered asio.h header named "Vestige" is mentioned in many places. However I see the PortAudio approach more feasible.
I think the reverse engineered header is this one: https://github.com/falkTX/dssi-vst/blob/master/vestige/aeffectx.h (https://github.com/falkTX/dssi-vst/blob/master/vestige/aeffectx.h), according to the conversation here: http://lmms-devel.narkive.com/HNAqQDiW/vst-header (http://lmms-devel.narkive.com/HNAqQDiW/vst-header). Unfortunately it won't provide the functionality that we need. So for ASIO, it looks like we'll need the official SDK.
I've also been doing some tests with WASAPI, and it seems to work fairly well with integrated cards, although ASIO will still provide lower latencies. The best WASAPI (event-driven exclusive, integrated card) was able to produce on my test rigs was ~3 ms, and I can't help but wonder if it's humanly possible to tell the difference between 3 and 1 ms. So WASAPI will probably work well for most users (integrated cards). However, I doubt it's worth the effort to do a native implementation, that time would be much better spent on PortAudio integration. This way, everyone can benefit from WASAPI, and people who really want to get the latency as low as possible will be able to compile their own binary with ASIO support (which will be illegal to redistribute). I've been testing ASIO with PortAudio, and it looks like it won't be adding any extra latency, so it will give the exact same performance that BASSASIO provides.
If the granularity problem is related to the m_speed variable being an integer, I guess this could be easily changed to use a float or any other way that provides an arbitrary degree of accuracy. From the top of my head, m_speed is just used in a couple of places, one being the final sound resampler, so the possibility of breaking something is limited. Although I'm probably missing the issue.
Some info about changing the sample rate on the fly can be found in this post: http://forum.arcadecontrols.com/index.php/topic,142143.msg1545886.html#msg1545886 (http://forum.arcadecontrols.com/index.php/topic,142143.msg1545886.html#msg1545886). I suspect most (all?) of the magic happens in sound_stream::generate_resampled_data.
-
I'm trying to figure out how something that is open source can be retroactively "illegal" when complied outside of a license that didn't exist when said release was done.
-
I'm trying to figure out how something that is open source can be retroactively "illegal" when complied outside of a license that didn't exist when said release was done.
0.171 must still be OK to distribute. 0.172 and onwards are problematic. Perhaps it would also be OK to distribute the source, but it's better to focus on a solution that could be added to mainline at some point.
-
I'm trying to figure out how something that is open source can be retroactively "illegal" when complied outside of a license that didn't exist when said release was done.
0.171 must still be OK to distribute. 0.172 and onwards are problematic. Perhaps it would also be OK to distribute the source, but it's better to focus on a solution that could be added to mainline at some point.
Exactly what I was getting at. I am beyond OK with sitting at .171 right now. ASIO is legit, d3d9ex is outstanding, and the groovy handles everything else is unparalleled. We don't have anything solid (that I've seen just yet) with how the Calamity stuff has dropped into mainline MAME. Holding pattern.
-
I'm very sorry if it has been mentioned, but my eyes are bleeding.
Has there been a Hyperspin Fix in some way for Realtek?
-
Has there been a Hyperspin Fix in some way for Realtek?
Not that I know of.
-
I am looking for a simpel frontend which would work with GM 171 ASIO on Win 7 64bit with CRT_Emu 2.0 drivers - any ideas?
-
I am looking for a simpel frontend which would work with GM 171 ASIO on Win 7 64bit with CRT_Emu 2.0 drivers - any ideas?
AttractMode (http://www.attractmode.org (http://www.attractmode.org)) works fine. I believe Big Blue (https://sites.google.com/site/bigbluefrontend/ (https://sites.google.com/site/bigbluefrontend/)) does too.
-
I will give AttractMode a try.
I already briefly tried getting Big Blue to work, however had no success - not sure whether its because I was using Win 7 64bit but it would not launch.
-
I am looking for a simpel frontend which would work with GM 171 ASIO on Win 7 64bit with CRT_Emu 2.0 drivers - any ideas?
I use MaLa on my MAME cabs with this setup. Works great for me, apart from a few minor bugs...
-
Just downloaded and installed AttractMode - just tested briefly, but seems to be working perfectly - thanks.
-
Hy everyone, this is my first time with Groovymame and I decided to download the GM ASIO ALPHA 0.171. Now I have a question: How can I understand if my sound card support Asio? There's a method or program to make it. Thank you
-
Hello, if you're using integrated audio, ASIO4ALL can be used. See the tutorial in the first post.
-
Hi, does someone know where I can download the asio gmame build for 0.161? I think the file might be called gmame161-asio.zip? I would like to do some testing with the 0.161 romset. Thanks!
-
Ok the download link in this post from intealls still works fine so I grabbed that. Luckily the 0.162 version should do nicely for the asio tests I need to run. I am hoping this build will help with some minor audio issues I am having with pacman/galaga/dkong that otherwise run in Mame Nirvana with Calamity's awesome CRT_Emu drivers. Thanks!
=================
Re: GM ASIO PRE-ALPHA
« Reply #51 on: May 30, 2015, 04:02:37 pm »
Quote from: vicosku on May 29, 2015, 11:02:03 am
Quote from: intealls on May 28, 2015, 03:00:54 pm
. I could patch up the latest GM and refresh my memory a bit, I'll probably have it done sometime this weekend.
I forgot to mention that I would greatly appreciate this. I haven't investigated how to do it myself yet. Now that MAME and MESS are merged as of .162, would this mean that the ASIO functionality would work with MESS drivers as well?
Thanks alot for your tests. Great to know that the ASIO stuff does not seem to affect the input latency.
Building with ASIO is a pain right now, since MAME just recently updated its build system, and GMASIO (64-bit) needs to be built using Visual Studio. I also had to employ a couple of truly terrible hacks to the sound structures, since there were changes there a couple of versions back.
Nonetheless, here's 0.162 :) It includes both MAME and MESS.
http://www.mediafire.com/download/n2jyl6f773p530h/gmame162-asio.zip (http://www.mediafire.com/download/n2jyl6f773p530h/gmame162-asio.zip)
EDIT: Also, -audio_latency 5.0 is no longer needed. The only parameter that affects the latency is -asio_holdoff (and of couse the latency of the ASIO driver).
« Last Edit: May 30, 2015, 04:11:50 pm by intealls »
-
I wanted to test what I had at hand before trying to track down the latest builds because either the links are gone in this thread or mega.nz is reporting file is no longer available. ..
-
Why are going this route instead of newer mame builds with (low latency) Port Audio?
-
Why are going this route instead of newer mame builds with (low latency) Port Audio?
I was wondering the same... see here (http://forum.arcadecontrols.com/index.php/topic,151459.msg1603357.html#msg1603357).
-
I was wondering the same... see here (http://forum.arcadecontrols.com/index.php/topic,151459.msg1603357.html#msg1603357).
It's pointless, and can potentially introduce legal issues due to the MAME license change.
This thread should be locked.