GM ASIO ALPHA 0.171

[Dr.Venom]

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

[intealls]

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.

Code: [Select]

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

Code: [Select]

(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:

Code: [Select]

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:

Code: [Select]

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

[vicosku]

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.

[Dr.Venom]

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?

[Dr.Venom]

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.

[vicosku]

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.

[intealls]

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.

[Dr.Venom]

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.
*/

[intealls]

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)

Code: [Select]

    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]

@ 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.

[Dr.Venom]

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?

[intealls]

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.

[vicosku]

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.

[Dr.Venom]

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.

[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,

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

[Dr.Venom]

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

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?

[intealls]

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).

[Dr.Venom]

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. 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..).   

[vicosku]

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.

[intealls]

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

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. 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/

[Paradroid]

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

[Dr.Venom]

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

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.

 

[intealls]

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

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.

[vicosku]

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!

[intealls]

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/. 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.

[intealls]

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/. 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.

[intealls]

Updated to 0.167. No major changes.

[vicosku]

Awesome.  Thanks for the quick update!

[Doozer]

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,

[intealls]

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.

[Doozer]

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

[Doozer]

@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]

@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?

[Doozer]

Let's start with embedded audio controller on a nforce based motherboard. Here is the default SLD alsa audio configuration.

Audio hardware:

Code: [Select]

Realtek ALC262
Audio device: NVIDIA Corporation MCP73 High Definition Audio (rev a1)

# cat /proc/asound/card0/pcm0p/sub0/hw_params

Code: [Select]

access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 1024
buffer_size: 16384

Groovymame log:

Code: [Select]

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

Code: [Select]

ALSA lib pcm.c:7905:(snd_pcm_recover) underrun occurred


[intealls]

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.

[Doozer]

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

[intealls]

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).

Code: [Select]

+++ 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();


[donluca]

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.

[intealls]

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.

[intealls]

Bump to 0.168.