GroovyMAME speed questions

[intealls]

Hi, first of all, THANK YOU for GroovyMAME and CRT Emudriver. They're utterly and completely awesome.

The last couple of weeks I've been hacking away at an ASIO implementation for GroovyMAME, using BASSASIO. I've gotten it to the point where it seemingly works well if the game is running at a consistent speed. Before raising anyone's hopes that this implementation will provide close to PCB-level latency, it won't, but it will most likely provide a lower latency than DirectSound (haven't done any comparisons yet).

I'm using -frame_delay 7 on an i3 3.4GHz. If the monitor preset is set to generic_15, a plot (about 320 seconds) of the current speed of pbobble (as reported by machine->video->speed_percent), looks like the attached pbobble_generic_15_fd7.png. pbobble runs at 60.00 Hz.

This wreaks havoc with my implementation (underruns etc).

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.

Another plot of neodrift (59.185606 Hz) is shown in neodrift_generic_15_fd7.png, displaying almost the same thing, but not as regular as pbobble. The first oscillations appear on the title screen (about 6000 samples in).

Custom (15625-15750,59.25-59.25,2.000,4.700,8.000,0.064,0.192,1.024,0,0,192,240,0,0) is shown in neodrift_custom_fd7.png.

The common command line options used during testing are the following; -nodisable_loading_patch -v -video d3d -waitvsync -syncrefresh -nosleep -priority 1

The executable is 32-bit, built with mamedev's 20121207 package, running on Windows 7 with CRT Emudriver 13.1 1.2b reloaded.

Am I missing something? When using a lower frame_delay value, the speed variations appear to be lower (see neodrift_generic_15_fd3.png), but still occur at roughly the same places in time. Is frame_delay working properly if the actual refresh rate isn't very close to the game refresh? I could really use some help understanding this.

[cools]

Try with directdraw, without framedelay.

[Calamity]

Hi intealls,

I'm impressed with your achievement, really.

Is frame_delay working properly if the actual refresh rate isn't very close to the game refresh? I could really use some help understanding this.

The experimental option -frame_delay is really meant as a per game adjustment. I'd say the problem you're facing is that the refresh that GM is outputting is slightly different to the native one. This of course is expected, due to dotclock granularity. Usually GM solves this situation by re-synchronizing the audio, but this is not possible when -frame_delay is on. The best approach may be creating a custom modeline *instead* of a custom crt_range. For doing this, run the target game with the generic settings. Then exit. On the clip-board there will be a copy of the last modeline used. Open notepad and paste it there. Then open Arcade OSD, launch a video mode with the same height and width, enter the modeline submenu and edit the values to match the ones in notepad. Then press "5" to test the refresh. Then try to fine tune the refresh to see if you can do a better approximation. A typical trick is to add extra lines to the back and front vertical porches alternatively, one by one, then readjusting the dotclock to match the refresh. If you succeed, copy the modeline values back into notepad and simply put that raw modeline inside the target game ini.

[intealls]

The experimental option -frame_delay is really meant as a per game adjustment. I'd say the problem you're facing is that the refresh that GM is outputting is slightly different to the native one.

Thanks for your replies!

I measured the frequency of the VSYNC lead with an oscilloscope, and they are different just as you say. However, I don't think that solely accounts for the regular speed fluctuations in for instance pbobble, I think the problem might be related (intertwined?) to the throttling mechanism, however my knowledge of the internal working of the MAME video system is very limited. I'm going to experiment with custom modes to see if the fluctuations can be avoided.

Following cools tip, running without frame_delay and with ddraw appears to give consistent speeds. I'm gonna do some more testing, and if you guys are interested, I can post the (highly experimental) patch (hopefully) sometime next week, when the code has been cleaned up a bit.

[Calamity]

Hi intealls,

Yep, I totally misunderstood your plots, now I see what you mean. I have always seen fluctuations in the speed when enabling -frame_delay. But I always thought they were artifacts of the speed measurement routine that gets affected by the -frame_delay option. The reason is I'm positive that the scrolls were smooth (and I have a trained eye for this), and this would be *impossible* if the speed fluctuations were real. Now you make me doubt.

But are you sure there's a link between the buffer underruns and the speed fluctuations? I'm tempted to think there's not.

By the way have you read this thread?: http://forum.arcadecontrols.com/index.php/topic,135230.40.html

[intealls]

Hi intealls,

Yep, I totally misunderstood your plots, now I see what you mean. I have always seen fluctuations in the speed when enabling -frame_delay. But I always thought they were artifacts of the speed measurement routine that gets affected by the -frame_delay option. The reason is I'm positive that the scrolls were smooth (and I have a trained eye for this), and this would be *impossible* if the speed fluctuations were real. Now you make me doubt.

But are you sure there's a link between the buffer underruns and the speed fluctuations? I'm tempted to think there's not.

By the way have you read this thread?: http://forum.arcadecontrols.com/index.php/topic,135230.40.html

You're absolutely right that they're not directly linked, it's due to my implementation/laziness. What happens in regards to the underruns is shown in buffer.png. The speed is on the top, and the size of the buffer on the bottom. When a fluctuation occurs, my buffer gets an extra bunch of samples. After 4 fluctuations, my buffer overruns, and since I don't handle overruns gracefully, I get underruns while everything catches up. These issues can be fixed rather easily.

However, after each fluctuation, the audio will lag a bit more. If using a large buffer, the result is as buffer_large.png, the plot shows that we're about 18000 samples behind. This will most likely be harder to fix, without noticing skips/pitch shifts in the audio. So the fluctuations do wreak havoc for the implementation. :/

However, when the speed is consistent, we get the result shown in buffer_con.png, it still underruns occasionally, but this can be fixed.

In regards to the thread, I tried enabling and disabling useplatformclock. My QPC frequency is apparently 3.320361 MHz, regardless whether activated or deactivated, ~14 MHz with bcdedit /set useplatformclock yes, after reboot, however, the fluctuations still occur. :/ Tomorrow, I'm going to see if the motherboard has an option to disable/enable the HPET, and read the thread more thoroughly. Interesting stuff!

I also attached a patch for GM of how the speed is logged, it simply writes to a file every time update_audio_stream is called (50 times/sec standard, 125 times/sec with ASIO).

[Calamity]

If you're using the m_machine.video().speed_percent() value for something critical to your implementation, then that will probably be an issue. This value is not reliable when -frame_delay is used. I guess we should find a solution for this at some point, but I haven't had the chance to research this. For this very reason I have to disable the "soundsync" implementation in GM when -frame_delay is used:

This is in src\emu\video.c, video_manager::recompute_speed

Code: [Select]

if (m_syncrefresh && m_throttled && m_framedelay == 0)
m_speed = m_speed_percent * 1000;
If you really need the speed percent for some reason, it is probably better to just setup a frame counter and compute the average speed in hertzs by simply dividing the frame counter by the elapsed machine time.

An even better solution is to ignore the emulation speed and simply check how many remaining/missing samples are in the sound buffer each time update buffer is called. Based on that, dynamically compute a resample factor to be applied to the stream... yeah, the libretro approach

This is not required when frame_delay is off because then the speed percent is reliable and we can use it as a base for the resample factor (our "soundsync" implementation).

[intealls]

If you're using the m_machine.video().speed_percent() value for something critical to your implementation, then that will probably be an issue. This value is not reliable when -frame_delay is used.

The plot buffer_large.png shows that when fluctuations occur, bursts of samples are delivered, no bursts are evident when no there are no fluctuations (buffer_con.png). However, this doesn't necessarily mean that speed_percent is reliable, just as you say.

In the above plots (with frame_delay), speed_percent is used to compensate for dotclock granularity. For each ASIO channel, BASSASIO has a built-in 16-point sinc resampler (which is awesome), I either force a specific resample rate at startup, or use speed_percent to dynamically deduce one. If the speed is consistent, either option seem to work (ish).

However, I think I should try to make sense of everything without frame_delay at the moment. I also _really_ need to measure the frequency of the BASSASIO callback, to get an estimate of the rate the sound card actually outputs (SB Live! with kX drivers), before doing anything else.

For this very reason I have to disable the "soundsync" implementation in GM when -frame_delay is used:

This is in src\emu\video.c, video_manager::recompute_speed

Code: [Select]

if (m_syncrefresh && m_throttled && m_framedelay == 0)
m_speed = m_speed_percent * 1000;

Thanks for the hint! After measuring the rate, I'm going to fiddle a bit with soundsync and BASSASIO's resampler, without frame_delay with the help of speed_percent.

[intealls]

Good progress has been made! I've disabled soundsync and frame_delay, and use BASSASIO to sync up the audio. I measured the frequency of the BASSASIO callback with the SB Live! to about 47999.4 Hz, and use this together with speed_percent to get a final, (hopefully) correct resampling rate to be used with BASSASIO. Preliminary testing seems promising.

Two plots are attached, a ~15 minute run of pbobble, the plot shows the number of incoming samples minus the number of outgoing at each call to update_audio_stream. The resulting value is negative simply because BASSASIO and GM sound output don't start in sync. So, don't mind the scale, the thing that's great about the plot is its consistency, without any forced resampling rates or anything. This level of consistency is truly excellent.

The second plot shows a 25 minute run of 720 degrees, with the same consistency.

Thank you again Calamity for the info! Things have really sped up now.

[intealls]

Alright, before releasing the preliminary, experimental and dangerous patch, I decided to do some comparisons with Direct Sound.

The measurements were taken with an Analog Discovery USB-based oscilloscope.

The options used are -monitor generic_15 -nodisable_loading_patch -nodisable_nagscreen_patch -v -video ddraw -waitvsync -syncrefresh -nosleep -priority 1 and the game was pbobble. Test mode was entered, and sound number 5 in sound test was played. The orange plot shows when input from the pressed button was registered by the USB keyboard firmware (sometime before sending the USB report to the computer), and the green plot shows when sound was output from the sound card. So this shows the actual, real audio latency on my current setup. I haven't increased the USB polling rate or anything like that, or tried to reduce input latency by any other means, these tests were just made to get an idea of the possible improvement of using BASSASIO instead of DirectSound.

DirectSound was used with an -audio_latency setting of 1.0, with a Realtek ALC887, which was used since FreqTest tells me that chip is considerably more stable than my SB Live! (Live!/kX driver: 47997.509/48002.427/48045.958, ALC887/native Windows driver: 47997.566/47997.631/47997.751).

Output with -v/DirectSound gave me; Sound: buffer overflows=11 underflows=0, and the game was played for around 5 minutes.

All values are in milliseconds.

Code: [Select]

>> dsound = [161.5, 157, 152.5, 173, 166, 149, 163, 158.5, 167.5, 180, 148.5, 163.5, 162, 164.5, 170.5, 160.5, 175.5, 163.5, 178, 170.5, 154.5, 169, 155.5, 166.5, 169];
>> mean(dsound)

ans =

  163.9800

>> max(dsound)

ans =

   180

>> min(dsound)

ans =

  148.5000

>> asio = [87, 88, 81, 77.5, 88.5, 100.5, 96.5, 84, 79, 95, 89, 85.5, 97.5, 99.5, 84, 90, 78, 86.5, 92, 94.5, 93, 74.5, 97.5, 93, 78];
>> mean(asio)

ans =

   88.3800

>> max(asio)

ans =

  100.5000

>> min(asio)

ans =

   74.5000
 

So, there's a definite improvement (at least on my setup), and there should be, so I suppose further work on the implementation is warranted.

Also, thank you Calamity for pointing me towards the QPC thread (and a big shout to Dr Venom for all his research!). The only time I've managed to get consistent and proper results is when QueryPerformanceFrequency reports 3.320361 MHz. This will most likely cause lots of problems depending on configuration.

If anyone wants me to do more testing, I'd be more than happy to, or if you can spot any flaws with my measurements/methodology, please tell me.

[Calamity]

Hi intealls,

Awesome work. I need to read it more thoroughly, but the first question that comes to my mind is... you mentioned the audio_latency 1.0 setting for dsound, but what setting are you using for BASSASIO, or does your patch already go for the least possible latency?

[intealls]

Hi intealls,

Awesome work. I need to read it more thoroughly, but the first question that comes to my mind is... you mentioned the audio_latency 1.0 setting for dsound, but what setting are you using for BASSASIO, or does your patch already go for the least possible latency?

Hi Calamity, it does. The intermediary buffer between GM and BASSASIO can be configured to almost underrun all the time, which is pretty cool. I'd say that next on the agenda, after sorting out all QPC-related stuff and making the implementation robust, work should be done to lower the latency even more (it must be possible!). I attached another scope plot of using a bundled BASSASIO test application (synth), and measured the latency of that, the actual latency (input is read using ReadConsoleInput) seems to be somewhere between 8 and 11 ms from button press to sound output, so this can (probably) be safely subtracted from the results. I don't know how much latency the actual pbobble hardware produces, which is also a major problem. I have access to a Magic Sword PCB, and will take some measurements on that later on.

Also, my understanding of the GM sound system is really limited. GM gives me samples, and I play them using BASSASIO. I've upped the update_audio_stream timer from 50 to 125 Hz, without really understanding the implications, so I'd say in order to get the best possible latency, a better understanding of the sound system is crucial. ASIO gives us the means for next to realtime audio, so it would be almost criminal not to make the most of it.

I'm almost finished with the clean-up, and have done a write-up of some common kX driver-related problems, which is the cheapest way to get ASIO up and running, kX is also the only ASIO-capable driver I have used for any longer period of time during development. Hopefully, I can release the patch in a day or two. Also, the BASSASIO callback frequency measurement tool will need to run for a couple of hours, which is a hell of a lot longer than it really should so I need to fiddle with that as well (not a priority now).

[intealls]

First off, thank you again Calamity for all your awesome work on GroovyMAME/CRT Emudriver. After years of fiddling with Linux, I'm never, ever going back.

After a bit of clean-up, here's the preliminary GM+BASSASIO patch, with a great big wall of text over it. Keep in mind that the patch is EXPERIMENTAL and UNFINISHED. It has also only been tested on two computers (they were both using Windows 7 and the kX driver, more on that below). With that said, it can sound really good if run under the right circumstances (fast computer, sober QPC and the right -asio_cal_freq, more about that in the next section and in _Usage).

_Introduction

I've decided to release the patch without any buffer management tricks in the implementation (like for instance forcibly try to keep a specified number of samples in the buffer for underrun mitigation). This will clutter the code less, and make it easier to understand if others want to mess around with it. The downside is that underruns can be more frequent. Overruns should be very infrequent, if the game speed is consistent, the QPC is sober, and -asio_cal_freq (see _Usage) is set correctly, -audio_latency is set to 5 (more info in _Usage), and nothing besides GM is running (with -nosleep and -priority 1).

_Steps to getting things running

* Acquire an ASIO-capable card and install its ASIO driver, or install ASIO4ALL and try that
* Build (see _Building)
* Use batool (GM root dir\batool) to get an estimate of the callback frequency (more info in _Usage)
- IMPORTANT ISSUES WITH BATOOL/QPC: I have noticed that the calibrated value WILL differ if the QPC frequency changes. On my i3-4130, the QPC frequency is set on boot, and changes on almost every boot (even with SpeedStep disabled). I currently work around this by using the platform clock (bcdedit /set useplatformclock yes), see the thread Calamity linked earlier for more info on this. For a really good measurement, you should probably leave batool running for an hour or two, so make absolutely sure you're getting a consistent QPC frequency in order to not have to redo the measurement. I'd recommend something like 20 mins/pass, 9 passes. This long measurement time will need to be fixed eventually, since it's pretty ridiculous.
* Run and specify the callback frequency with -asio_cal_freq
* If you want to know what's really going on, use -asio_log and read the _Usage section carefully

_ASIO4ALL info
As of rev2, ASIO4ALL support has been fixed. Depending on the sound card used, excellent results can be achieved. My Realtek ALC887 seems to be able to provide a latency of about 100, and my Realtek ALC889 seems to provide a latency of 78! The device to be used and latency is configured by using the ASIO4ALL tray icon (make sure to install with 'Use offline settings' checked) that appears when running GM, so run it with -window, and configure everything. I'll post better instructions later on.

_kX info

The cheapest way to get an ASIO capable card (if ASIO4ALL does not work satisfactorily) is to use an old Sound Blaster Live!/Audigy etc with the kX project driver, available at http://www.kxproject.com . This is what has been used during development (Audigy 2 ZS and Live!). I highly recommend driver version 3551, found at http://www.hardwareheaven.com/community/threads/3551-alpha-released.206609/ . If ASIO won't work after installing the driver, follow the guidelines in this post: http://www.hardwareheaven.com/community/threads/no-asio-driver-under-windows-7-32bit.218926/#post-1470886 . Simply doing the regsvr32-trick solved it for me. If using 64-bit, make sure to register both C:\Program Files (x86)\kX Project\kxasio.dll and C:\Program Files\kX Project\kxasio.dll to enable both the 32- and 64-bit driver.

Also, you hopefully won't need to use a buffer size of anything other than 64. Specify ASIO buffer size with the -asio_latency setting, when everything's up and running. If you'd like to access the ASIO control panel (to configure the kX driver latency), and the kX tray icon won't let you, you can use batool (info below) with the --cp switch to access it.

If no sound is being output but everything else seems to work, try another jack on the sound card.

I've tested the official Sound Blaster ASIO driver, which seems to work (Audigy 2 ZS, Windows 7). The kX driver delivers far superior results though. ASIO4ALL does not work.

_Building

With MinGW, only 32-bit builds are supported. So make sure you're using the 32-bit MinGW toolchain. Only the mingw-mame-20121207.exe package has been tested. mingw-mame-20140905.exe works and should be used.

Before building, apply all GroovyMAME (0.154/0.155) patches, then apply asio_rev*.patch.

Download BASSASIO from here http://www.un4seen.com/download.php?bassasio13 . Create a directory in the GM root directory (same as makefile) called 'bassasio' and extract the contents of the archive into this directory.

Now you should be able to compile as normal. I build with the following options:

Code: [Select]

-j5 TARGETOS=win32 TARGET=mame OSD=windows ARCHOPTS=-march=pentiumpro NOWERROR=1

As of rev2, 64-bit builds are supported with the MSVC compiler (VS2013), however, I had to make three hackish changes to GM. Make sure you have a working MSVC setup and use the following switches to build.

Code: [Select]

MSVC_BUILD=1 NOWERROR=1 DIRECTINPUT=8 PTR64=1
_Usage

To get good results you need a fairly fast computer (I'm using an i3-4130, testing has also been done on a i5-2500K), also make sure you have next to nothing running in the background. So, disable unnecessary services etc, this is especially important if using -asio_log (more info below).

The frequency of the BASSASIO callback must be measured for proper operation. Use batool to do this (root dir\batool), and the GM command line switch -asio_cal_freq to specify the value. My Audigy 2 ZS apparently runs at about 47998 Hz and my Live! at about 47999.4 Hz 47998.65 (with platform clock enabled). If not compensated for, this will cause the audio to drift. The QPC clock can (amongst other things) affect the measurement, this will need to be investigated further.

Only DirectDraw has been tested. Using the -v option gives useful debug information. The options used during testing are the ones below.

Code: [Select]

mame -v -waitvsync -syncrefresh -nosleep -priority 1 -monitor generic_15 -video ddraw -asio_latency 64 -asio_log -audio_latency 5 -asio_cal_freq <calibrated value>

The -audio_latency parameter does not work the same way as with DirectSound, it merely sets the size of the intermediary buffer. If lots of underruns are shown in the log, try setting -audio_latency 5 and -asio_holdoff 1152.

If run with -asio_log, a log will be output to 'asio.log'. The easiest way to use this log is probably with Octave (or better, MATLAB, if you have it). Octave can be downloaded from http://mxeoctave.osuv.de . After installing, start up the command line version and paste

Code: [Select]

data = csvread('<path to asio.log>'); subplot(3, 1, 1), plot(data(:,8), data(:,1)), subplot(3, 1, 2), plot(data(:,8), data(:,3) - data(:,4)), subplot(3, 1, 3), plot(data(:,8), data(:,2));

to plot recorded speed against audio update count (top), incoming minus outgoing samples at each audio update (middle), and the internal buffer count (of channel 0) against audio update count (bottom). This is an almost invaluable tool when debugging. Also, it's possible that the first time plotting, Octave will be a bit slow. Subsequent plots should be faster. All of this fiddlery should eventually be replaced with an under-/overrun counter message in the GM log.

_Problems
Currently, the game needs to be running at a very consistent speed.

Sometimes, the left and right channels fall out of sync. This creates interesting effects.

The in-game volume control doesn't work.

No sound for the first three seconds.

-audio_latency won't affect the latency the same way as the DirectSound implementation.

Fastforward and pause won't work.

Actual latency may vary.

QPC variations can cause problems. Not sure what to do about this at present.

There are possible bugs in the intermediary buffer implementation.

Lots of other stuff I've forgotten to mention/don't know about.


With all this said, I will do the best I can to help out with any issues that arise.

rev0: Initial release
rev1: minor fix for the log/debug info, diff is made against 0.155!
rev2: 64-bit support with MSVC, fixes to batool, channel desync should be a lot less frequent, preliminary ASIO4ALL support
rev3: (very) preliminary buffer management stuff. DirectSound with soundsync can be used with -sound dsound
pa0: corresponds to pre-alpha 0

[Calamity]

Thanks intealls, this is BIG.

Before searching for a sound card, I gather that the typical integrated sound card won't support ASIO, is it true?

[cools]

Correct. You need an ASIO compatible driver, and I don't know of any integrated ones that have it. You could try ASIO4ALL but its not known for its effectiveness - I'd suggest for any dev work getting something proper, then when complete advise people that they could try ASIO4ALL before getting a proper card.

An old SB Live or Audigy should cost next to nothing, I'll happily fund one for you.

[intealls]

Thanks Calamity!

The implementation is very rough, as the above post describes. However, I think it has the potential to be absolutely awesome!

+1 what cools said. I tried ASIO4ALL, but could not get it to work properly. See the long post above.

Also, I forgot to mention that not all Live!/Audigy cards are supported by the kX driver. Here's a link to the list of cards that are supported: http://www.kxproject.com/faq.php?language=en#Q15 .

[adder]

Also, I forgot to mention that not all Live!/Audigy cards are supported by the kX driver. Here's a link to the list of cards that are supported: http://www.kxproject.com/faq.php?language=en#Q15

great the Soundblaster Live! 5.1 cards (SB022x) are cheap and plentiful on ebay.

[cools]

Got an Audigy 2 on the way for £5 shipped

[intealls]

Got an Audigy 2 on the way for £5 shipped

Nice! I'm back at work, so I won't be able to work on the implementation as much as the past two weeks. But hopefully, with just a few minor tweaks, I think a good portion of games will run alright.

Also, the most tedious part currently is the need to force the use of the platform clock, and the need to measure the frequency of the BASSASIO callback. I hope I'll be able work around this and deduce the frequency of the callback when GM is running.

[timply]

This is very interesting stuff. I have an Audigy 2 laying around somewhere so I may try it out. I hope you continue to work on this project.

[intealls]

This is very interesting stuff. I have an Audigy 2 laying around somewhere so I may try it out. I hope you continue to work on this project.

I'm still giving it a lot of time. Also, preliminary testing shows that the ASIO4ALL driver seems to work very well when using integrated cards, which really simplifies things. Also, it's not impossible that an alpha-alpha binary might show up in a day or two.