The NEW Build Your Own Arcade Controls

Software Support => GroovyMAME => Topic started by: Dr.Venom on October 20, 2013, 04:32:54 am

Title: Soundcard frequency stability test - please add your results
Post by: Dr.Venom on October 20, 2013, 04:32:54 am
Hi,

I noticed something interesting that is affecting GroovyMAME (audio) emulation accuracy. Short introduction first on the issue and then for the test and test results. It's also a very simple test, so if you have a minute, please report back, and I'll collect them in this first post.

One part in the chain of accurate emulation is the soundcard frequency stability, i.e. does it always exactly return the requested playback rate? Because if not, it will lead to a more unstable soundbuffer, which will cause soundbuffer over-/underflows (missing audio) at lower audio latency settings. Or said differently, the more stable the soundcard, the lower you can set the MAME audio latency without it causing issues, the more accurate the emulation gets.

Because GM didn't seem to be able to get as low a -stable- sound latency as I would expect it to be able to for DirectSound (the windows api used by MAME), I've been digging around deeper. First in the code, which didn't help, then looking at the soundcards more closely. Now to my total surprise I found that on two of my high end PC's, the high end soundcards that I've got in there (one an Auzentech X-Fi Forte and the other a Creative SB X-Fi) don't deliver a stable rate at all! Switching over to the Realtek ALC898 onboard audio delivered rocksteady audio, and allowed me to lower the audio latency in GroovyMAME by quite some margin, very close to a setting of 1, -without- it leading to any buffer over-/underflows.

Doing the soundcard frequency tests for all three, showed how unstable both X-Fi cards were, and how very stable the Realtek ALC898 is! The tests are done with the tool FreqTest, which requests a sample played at 48Khz a number of times and calculates the actual frequency that is returned by the soundcard, providing a "min", "avg" and "max" value. Ideally these values are the same , as that means there's no invariabilty and as such the highest possible stability for MAME audio emulation.

Here are the results:
(EDIT: other user results added to the table. Order is from best to worse.)

CardMin (Hz)Avg (Hz)Max (Hz)OSInterfaceUser
Realtek ALC86148000,01848000,03048000,080Vista x64On-boardSMMM
Sound Blaster X-Fi XtremeGamer47998,99547999,0547999,099XP x64PCIKrick
Auzentech X-Fi Prelude 7.147998,72047998,81047998,897XP x86PCIGoglu2
Realtek ALC26947998,29847998,67647998,934W7 x64On-boardCalamity
Nvidia 550Ti (HDMI out)47998,44047998,45647998,472W7 x64PCI ExpressSMMM
SIGMATEL STAC 92XX C-Major HD Audio47998,20047998,24447998,275W7 x64On-boardCalamity
Realtek ALC892    47997,94647998,00247998,054W7 x64On-boardbulbousbeard
Realtek ALC887   47997,92747997,95147997,971W7 x64On-boardKrick
Realtek ALC85047997,93447997,94147997,959W7 x64On-boarddeathterrapin
Realtek ALC898    47997,25247997,26247997,292W7 x64On-boardDr.Venom
SIGMATEL STAC 92XX C-Major HD Audio48008,41548008,48548008,574XP x64On-boardCalamity
Realtek ALC66247973,22147976,50747993,630XP x64On-boardCalamity
C-Media USB CM10647997,93248002,74248045,940W7 x64USBdeathterrapin
VIA VT1828S47997,24548002,06048045,268W7 x64On-BoardSMMM
Auzentech X-Fi Forte   47997,23248002,05748045,257W7 x64PCI ExpressDr.Venom
C-Media USB unknown (0D8C 000E)47973,47147975,03747978,460XP x64USBdeathterrapin
C-Media USB CM10647973,47847974,89947978,343XP x64USBdeathterrapin
Realtek ALC889 47950,41747993,64547998,486W7 x64On-BoardSMMM
Creative SB X-Fi   47949,26148006,38048045,260W7 x64PCI ExpressDr.Venom
Asus Xonar DG47949,25248006,86348093,336W7 x64PCISMMM
Realtek ALC889a47873,47247946,74748026,595W7 x64On-boardJDFan

Now, as can be seen the RealTek ALC898 delivered by far the most stable results when compared to both my Auzentech and Creative X-Fi cards. The Realtek results in the possibility to now set a much lower audio latency setting in MAME then with the X-Fi cards, without it causing audio issues (buffer over-/underflows).

Now I was actually quite surprised that the expensive high-end soundcards deliver such poor stability results. But it's not the first time we may be surprised on PC hard-/software.

Given this I'm wondering what the results are for other soundcards / OS setups? Hopefully you'll submit your own results. The procedure is actually quite simple:

1. Make sure that you have set your audio device in windows to work at 16-bit 48Khz (configuration->audio panel -> right mouse button on default audio device -> select properties and then "advanced" and set it to 16-bit 48000Hz). *Note: this first step is important, as having the default audio device at any other rate then 48Khz, will cause FreqTest to deliver false results, because of resampling between the requested 48Khz and the default rate set in Windows.*
2. Start the attached "FreqTest.exe" (the archive includes both a 32 and 64 bit version) and wait for a few minutes. It will first test the screen frequency and then the audio test. The result will be like the picture below. The relevant part "sample rate" is highlighted in the red square:

(http://i40.tinypic.com/wjfale.png)

3. Report back here with your soundcard, OS and the "sample rate" results.

If possible, I'll collect all the other results in the first post, such that we build a list on the best / most stable audio cards for use with MAME. Even if your card is the same as already reported by someone else in the test results, then please still report back with your own, as the stability may possibly also be OS / driver dependant. The more information the better.
Title: Re: Soundcard frequency stability test - please add your results
Post by: deathterrapin on October 20, 2013, 06:24:56 am
Realtek ALC850 47997.934    47997.941    47997.959    W7
C-Media USB CM106    47997.932    48002.742    48045.94    W7
C-Media USB CM106    47973.478    47974.899    47978.343    XP x64
C-Media USB unknown (0D8C 000E)    47973.471    47975.037    47978.46    XP x64

The first two of those are on my main pc, the others two on my cab pc.
I would suspect that the different behavior of the CM106 between the two is more to do with the different motherboard rather than the OS.

I'll be interested to see if anything useful comes out of this. I've never quite been able to get the audio perfect with groovymame on my cab pc.
Title: Re: Soundcard frequency stability test - please add your results
Post by: Dr.Venom on October 20, 2013, 08:52:25 am
Hi deathterrapin,

Thanks for adding your results. It's interesting to see that the Realtek soundchip is (again) delivering the most stable results. I'll add them to the first post.

I'll be interested to see if anything useful comes out of this. I've never quite been able to get the audio perfect with groovymame on my cab pc.

I'm not sure if I understand your comment "if anything useful comes out of this". In the first post it's explained that the more stable a soundcard, the better a solution it is for the audio emulation stability of MAME. So in your case - all else being equal - your MAME setup should include the Realtek ALC850, as it's the only one that's delivering fully stable sound output.
Title: Re: Soundcard frequency stability test - please add your results
Post by: deathterrapin on October 20, 2013, 09:34:40 am
I was thinking that it might be possible to modify the mame sound code to compensate for the unstable sound rates, now I think about it some more though that's probably just too hacky.
Title: Re: Soundcard frequency stability test - please add your results
Post by: Calamity on October 20, 2013, 02:11:19 pm
Here goes mine:

Realtek ALC269 47998.298 47998.676 47998.934 W7 x64

Realtek ALC662 47973.221 47976.507 47993.630 XP x64

The first one gives much better results, but it was necessary to set 16 bit /48 kHz, by default it was setup as 24 bit and it gave worse results. This audio bitrate config menu does not exist under Windows XP (!!??), so I don't know if the bad results of the second case are due to this.
Title: Re: Soundcard frequency stability test - please add your results
Post by: deathterrapin on October 20, 2013, 04:08:19 pm
Oh, my windows 7 machine is 64 bit as well btw. (I kind of forget there still is a 32 bit version sometimes :D)
Title: Re: Soundcard frequency stability test - please add your results
Post by: bulbousbeard on October 20, 2013, 04:58:51 pm
Realtek ALC892 on an Asus P8Z68-V PRO motherboard in Windows 7 x64

(http://i.imgur.com/VX0PoTX.png]http://i.imgur.com/VX0PoTX.png)
Title: Re: Soundcard frequency stability test - please add your results
Post by: JDFan on October 20, 2013, 06:34:51 pm
realtek alc889a
Title: Re: Soundcard frequency stability test - please add your results
Post by: Dr.Venom on October 21, 2013, 05:34:40 am
@ JDFan: What OS are you using?   If it's W7, did you apply step 1, as described in the first post?

@ Calamity: with regards to XP, I understand that in XP by default a single stream is played at the requested rate without sample rate conversion, as long as the sound device is capable of that sample rate. So your measured results for XP should be good.

There is some conversion setting though in the advanced panel that may impact things, which I think would be good to check.  So just to be sure, could you test all three different "sample rate conversion" settings ("good, better, best") in the advanced audio properties panel, as shown in the picture below. In case one of them delivers worse results (i.e. indicating unwanted, time consuming sample rate conversion going on), then I can add those to the instructions.

(http://km.support.apple.com/library/APPLE/APPLECARE_ALLGEOS/TS1362/en_US/93610_4.jpg)

With regards to the 16-bit 24-bit conversion in W7, I added the "16-bit" explicitly to the 48Khz setting instruction in step 1.
Title: Re: Soundcard frequency stability test - please add your results
Post by: Calamity on October 21, 2013, 07:15:07 am
Hi Dr., I did test that dialog with both "Better" and "Best" options and they didn't seem to make a change, I might test "Good" today too just to double check... it's a bit annoying when the OS hides the actual params under lame words.
Title: Re: Soundcard frequency stability test - please add your results
Post by: Calamity on October 21, 2013, 07:24:25 am
BTW the FreqTest program doesn't work under Win32.
Title: Re: Soundcard frequency stability test - please add your results
Post by: Dr.Venom on October 21, 2013, 11:05:20 am
Hi Dr., I did test that dialog with both "Better" and "Best" options and they didn't seem to make a change, I might test "Good" today too just to double check... it's a bit annoying when the OS hides the actual params under lame words.

LOL, Indeed :)

BTW the FreqTest program doesn't work under Win32.

Ah ok, I've added the 32-bit one also to the archive now.
Title: Re: Soundcard frequency stability test - please add your results
Post by: Calamity on October 21, 2013, 11:18:50 am
Ok, one more:

SIGMATEL STAC 92XX C-Major HD Audio  47998.200 47998.244 47998.275 W7 x64
SIGMATEL STAC 92XX C-Major HD Audio  48008.415 48008.485 48008.574 XP x64

Note this is the same physical card tested under two different OSes on my multi-boot system (an old Dell P4 with Intel chipset). Results are almost as good in either system, so this reinforces the idea that the performance is hardware dependent rather than OS.
Title: Re: Soundcard frequency stability test - please add your results
Post by: JDFan on October 21, 2013, 12:29:17 pm
@ JDFan: What OS are you using?   If it's W7, did you apply step 1, as described in the first post?

OS is win7 64 bit on a Gigabyte MOBO with realtek audio HD manager --I believe this is what you meant correct ?

Just rechecked the settings and somewhere win7 had changed the default to 24 bit rather than 16 bit for the speakers (Had looked at the digital output device originally) Here is the result after resetting the default for the speakers to 16 bit --
Title: Re: Soundcard frequency stability test - please add your results
Post by: brad808 on October 21, 2013, 12:56:30 pm
The sample rate conversion slider shouldn't make a difference because it shouldn't be converting the sample rate.

Sent from my Nexus 4

Title: Re: Soundcard frequency stability test - please add your results
Post by: krick on October 24, 2013, 12:24:35 pm
I think it might be useful to note whether the tested sound chip is on the motherboard vs a plug-in card.  It's possible that the PCI/PCIe bus is adding to the stability issue.

Another thought is that overclocking may affect the results.  In addition to manual overclocking by users, some motherboards do automatic overclocking in some situations for a performance boost.

I have a PCI Sound Blaster X-Fi XtremeGamer on Windows XP x-64 that I need to test for you when I get the chance.  I'm curious if I see the same results as you.

I also wonder about the chosen sample rates.  I know that some older hardware was designed for a certain target sample rate and had to re-sample internally to output other sample rates if requested, which could impact the results.   I would assume that most hardware designed for the general public would target 16-bit / 44.1kHz since that's what's used for compact discs.
Title: Re: Soundcard frequency stability test - please add your results
Post by: Dr.Venom on October 25, 2013, 05:10:45 am
Just rechecked the settings and somewhere win7 had changed the default to 24 bit rather than 16 bit for the speakers (Had looked at the digital output device originally) Here is the result after resetting the default for the speakers to 16 bit --

Hi JDFan. Thanks for rechecking the settings. I'll add the updated results to the table.

Note this is the same physical card tested under two different OSes on my multi-boot system (an old Dell P4 with Intel chipset). Results are almost as good in either system, so this reinforces the idea that the performance is hardware dependent rather than OS.

This would indeed suggest that the OS doesn't influence the stability, that's good to know.

I think it might be useful to note whether the tested sound chip is on the motherboard vs a plug-in card.  It's possible that the PCI/PCIe bus is adding to the stability issue.

Hi Krick. I'll add the motherboard vs plug-in card to the table.

With regards to the reasons for the instability, those are some relevant point you bring forward. Let's take them one by one:

1. Overclocking / automatic performance boost.
I have an I7 3770k overclocked at 4.6Ghz and the Realtek (on-board audio) delivers rocksteady results but the X-Fi does not in the same machine. This would suggest that overclocking isn't the main reason. In any case we would need some hypothesis and tests to prove otherwise.

2. (older) hardware was designed for a certain target sample rate (that could be different than 48Khz)

"Assuming" that chips work at 44.1Khz based on old CD technology isn't good enough ;).  I could say the opposite based on the assumption that people use their PCs to play DVD's (i.e. audio at 48Khz)... Sadly there's very little evidence what the native frequencies are of soundcards. Apparently the newer Creative cards work at 48Khz; just read some of the (many) forums with users complaining about their cards resampling audio to 48Khz . I'm also reading that there would be chips that are capable of having more than than one single native sample frequency.

From my personal tests I can tell that for the X-Fi cards it makes no difference whether I use them (and the MAME setting) at 44.1Khz or 48Khz, both settings are much more unstable (more buffer over-/underflows at the same audio latency setting) then when using the Realtek chip. 

Testing at 48Khz seems the right thing to do, as it happens to be the default MAME audio rate. So unless users deliberately change that, 48Khz is what's being used.

3. Motherboard vs a plug-in card.  It's possible that the PCI/PCIe bus is adding to the stability issue.

If I were to place my bets, this is where it would be. The results up until now would have suggested so, if it were not for JDFan's results: his Realtek onboard audio delivers about as unstable results as the X-Fi cards.

Quote
I have a PCI Sound Blaster X-Fi XtremeGamer on Windows XP x-64 that I need to test for you when I get the chance.  I'm curious if I see the same results as you.

Yes that will be interesting to see.

I have a spare Asus Xonar DX PCI Express card lying around, so I'll give that a test also as soon as I have the chance.


Edit: Table in first post updated.
Title: Re: Soundcard frequency stability test - please add your results
Post by: SMMM on October 25, 2013, 11:27:36 am
Asus Xonar DG | PCI | Win7x64
VIA VT1828S | On-Board | Win7x64
Realtek ALC889 | On-Board | Win7x64
Realtek ALC861 | On-Board | WinVistax64
Title: Re: Soundcard frequency stability test - please add your results
Post by: SMMM on October 25, 2013, 12:04:55 pm
HERE'S something interesting!  Check out the results I got from my Nvidia 550ti - video and audio through HDMI out.  PCI Express, Win7x64
Title: Re: Soundcard frequency stability test - please add your results
Post by: Dr.Venom on October 27, 2013, 05:19:49 am
Hi SMMM,

Thanks for adding all of your results. The Nvidia one is certainly interesting.

With regards to the results of the Asus Xonar DG, VIA VT1828S and Realtek ALC889, could you verify that in each separate test for these devices you ran through step 1 (from the first post)? I.e. that for each individual test the to be tested audio device was (re)set to be a) the default audio device and b) the sample rate of the device was set to "16 bit, 48000Hz (DVD Quality)", as shown in below pictures, before doing the test?

It's important that this is done correctly for each separate device, otherwise FreqTest will give false results. So I'd rather have it doublechecked, to be really sure the (unstable) results for these three devices are correct.

(http://i43.tinypic.com/2ez6vip.png)

(http://i39.tinypic.com/2vttklc.png)
Title: Re: Soundcard frequency stability test - please add your results
Post by: SMMM on October 27, 2013, 07:35:19 am
Yessir.  Did exactly that for each that I tested.  Set each as default device, 16-bit/48000hz, disabled all other sound devices.  The Realtek ALC889 is from a similar motherboard to that of JDFan's, I'm thinking.  It's a super cheap Gigabyte board I got for free in a processor/combo combo deal - worth about $40 brand new, lol.

Also, you typed the results for the Realtek ALC861   wrong in the opening post.  Should be much higher on the list.  :D
Title: Re: Soundcard frequency stability test - please add your results
Post by: Dr.Venom on October 27, 2013, 03:18:49 pm
Yessir.  Did exactly that for each that I tested.  Set each as default device, 16-bit/48000hz, disabled all other sound devices.  The Realtek ALC889 is from a similar motherboard to that of JDFan's, I'm thinking.  It's a super cheap Gigabyte board I got for free in a processor/combo combo deal - worth about $40 brand new, lol.

Great, thanks for confirming.

Is there a possibility that you could also test the ALC861 while running on Win7 and/or XP? Just in case you're running it in a multiboot environment already. Calamity's results for the Sigmatel showed that it may impact how close it comes to 48Khz, even though not impacting the variability. It would be interesting to know -if- and by how much the results would differ between the different OS's for this quite stable / accurate chip.

Quote
Also, you typed the results for the Realtek ALC861   wrong in the opening post.  Should be much higher on the list.  :D

Ah, no I didn't. The sort was based on "Max minus Min".  The idea being that the lower this "max minus min" value, the better you can/could address the "average" deviation in software. So something like 47997.000 with -no- variation would then actually be preferable to something like 48000.14 with -some- (however small) variation. But since we don't have any such patch in MAME, or will there be I guess, it's kind of moot sorting criterium.

 I've changed it to a new "Max plus Min" sorting criterium, where for both Max and Min the absolute deviations from 48Khz are now taken. I think you'll like the resulting "ranking" better ;)
Title: Re: Soundcard frequency stability test - please add your results
Post by: SMMM on October 27, 2013, 11:55:11 pm
Gotcha.  I like the new organization of the list, but I was talking about the numbers.  You have

48000,180   48000,300   48000,800

When they should be

48000,018   48000,030   48000,080

And the comp it's on is actually my file server PC running Server 2008 (a slightly modified version of Vista, using Vista drivers), so not much I can do to test it with XP and Win7 at the moment.
Title: Re: Soundcard frequency stability test - please add your results
Post by: Dr.Venom on October 28, 2013, 11:37:37 am
I see, missed that one. I guess that's why I prefer copy & paste  :D. I've updated the table with the correct numbers.

Out of interest, what manufacturer and model is the mainboard that contains the ALC861?  I'm thinking that maybe I should add a column for the motherboards used, possibly that'll provide us a clue to the accuracy / stability of the sound devices in general.
Title: Re: Soundcard frequency stability test - please add your results
Post by: SMMM on October 28, 2013, 02:22:48 pm
Card | Motherboard

Realtek ALC861 | Acer MCP61SM-AM
VIA VT1828S | MSI 870-G45
Realtek ALC889 | Gigabyte GA-78LMT-S2P
Title: Re: Soundcard frequency stability test - please add your results
Post by: krick on November 03, 2013, 01:53:16 am
PCI Sound Blaster X-Fi XtremeGamer on Windows XP x64

Sound Blaster X-Fi XtremeGamer   47,998.995   47,999.050   47,999.099   XP x64   PCI   Krick

If my calculations are correct, this is the new #2 card in your table.
Title: Re: Soundcard frequency stability test - please add your results
Post by: krick on November 03, 2013, 02:09:50 am
Onboard Realtek ALC887 (ASUS P8Z77-M motherboard) on Windows 7 x64

Realtek ALC887   47,997.927   47,997.951   47,997.971   W7 x64   On-board   Krick
Title: Re: Soundcard frequency stability test - please add your results
Post by: SMMM on November 03, 2013, 03:35:01 am
PCI Sound Blaster X-Fi XtremeGamer on Windows XP x64

Sound Blaster X-Fi XtremeGamer   47,998.995   47,999.050   47,999.099   XP x64   PCI   Krick

If my calculations are correct, this is the new #2 card in your table.

Neat!  Is this it?

http://us.store.creative.com/Sound-Blaster-XFi-XtremeGamer/M/B000J1F1BI.htm (http://us.store.creative.com/Sound-Blaster-XFi-XtremeGamer/M/B000J1F1BI.htm)
Title: Re: Soundcard frequency stability test - please add your results
Post by: krick on November 03, 2013, 09:26:15 pm
Yep.  I actually have two of those cards, but one doesn't work right.

One came with a low-profile bracket and has a serial number containing: "SB0730"
The other has a full-height bracket and has a serial number containing: "SB073A"

The only one that works is the "SB073A".  I think the other one is an older hardware revision that had issues.

Instead of using the CD that ships with the card, I recommend using one of these driver/software packs...

    SB X-Fi series Support Pack 2.5 (10/25/2011)
    http://forums.creative.com/showthread.php?t=587995 (http://forums.creative.com/showthread.php?t=587995)

    SB X-Fi Series AuzenForte Pack 2.0 (12/27/2012) based on the official Win 8 Auzen Forte driver
    http://forums.creative.com/showthread.php?t=699146 (http://forums.creative.com/showthread.php?t=699146)

I'm using the AuzenForte Pack 2.0 with my card.
Title: Re: Soundcard frequency stability test - please add your results
Post by: Goglu2 on November 03, 2013, 10:13:31 pm
Auzentech X-Fi Prelude 7.1 | PCI | WInXP 32Bit

Min. 47998.720Hz  Avg. 47998.810Hz  Max. 47998.897
Title: Re: Soundcard frequency stability test - please add your results
Post by: Dr.Venom on November 04, 2013, 04:55:57 am
Hi Krick and Goglu2,

Thanks for adding your results, I've updated the main table in the first post. I'm getting quite puzzled as to the common denominator to stability. Anyone with an educated guess? 

I guess to get a sense of whether it's the card or something else we would need verification of the currently tested cards by other users / in different setups. So if anyone has one of the already tested cards, please run the test with your setup (it'll only take you a minute) and let us know the results!

We do have to note that the FreqTest test is a DirectSound test afaik. This is relevant for the current MAME implementation, but it doesn't necessarily say something about other audio (low-latency) API's, like WASAPI-EX or ASIO. Of course this is irrelevant as long as MAME doesn't have such an implementation, but at least we can hope. At which time we would need a FreqTest program which can also work with these APIs, and revisit these tests. I guess that could lead lead to different result for the various cards.  In case anyone with proficient programming skill and MAME knowledge would be interested in the low latency API's, here are the links for possibly the "easiest" and most compatible way of implementing those:

PortAudio - An Open-Source Cross-Platform Audio API: http://www.portaudio.com/ (http://www.portaudio.com/)
ASIO4ALL - Universal ASIO Driver For WDM Audio: http://www.asio4all.com/ (http://www.asio4all.com/)


Title: Re: Soundcard frequency stability test - please add your results
Post by: Calamity on November 04, 2013, 07:54:59 am
Hi Dr.Venom,

Just to clarify, did you get good evidence when testing in your system that better results in FreqTest mean better sound "smoothness" in MAME (less buffer underruns/overflows)? I'm assuming the answer is yes.

This is way beyond my knowledge of things, but it would be interesting to find if the PCI port, IRQs, etc. have some role to play here too, so that there could be some room for tweaking from the BIOS side.
Title: Re: Soundcard frequency stability test - please add your results
Post by: Dr.Venom on November 04, 2013, 10:55:04 am
Hi Calamity,

Just to clarify, did you get good evidence when testing in your system that better results in FreqTest mean better sound "smoothness" in MAME (less buffer underruns/overflows)? I'm assuming the answer is yes.

It depends on what you call "good" evidence. I guess you remember the thread where we spoke about a patch that enables a higher granularity for the audio latency setting? The one that enables the audio latency setting to be set in increments of 0.1 (in windows the audio latency setting is directly related to the size of the soundbuffer, which is set according to the size of the audio latency setting in mame.ini). See here: http://forum.arcadecontrols.com/index.php?topic=130944.0. (http://forum.arcadecontrols.com/index.php?topic=130944.0.)

Given the use of that patch I noticed that with both my X-Fi cards I could only lower the sound_latency to 1.7 when using GroovyUME and the MESS MSX2 driver with Konami SCC games (these games contain more than one emulated soundchip) before there would be -NO- buffer over/-underruns at all when running the emulation for half an hour. The criterium was no over- or underruns at all. Then I tried the on-board Realtek and to my surprise I could lower the setting to 1.3 to get -no- buffer over-/underruns at all when running the same setup for half an hour. At first I though the default buffer sizes (that I'm logging in my personal build) for both chips differed, such that the settings would not be comparable. But they were the same. Then I got the idea to try the FreqTest on both chips, and these showed these large differences in stability (see the main table and explanation in first post).

So I could have lower -stable- soundsetting with the Realtek chip than the X-Fi's -AND- the Realtek chip showed a much more stable frequency stability result with FreqTest. Adding these two results together implied to me that they are related, and that's what made me post about it. That said, we could only be really sure if we had some professional test equipment to scientifically prove there's a latency difference between the two. So I guess the usual disclaimers apply.

In case there is a real relationship, my theory would be that MAME resamples all audio that the emulation core is generating to 48000Khz. So you have 48000 samples per second. Now if a soundcard would randomly play that stream at a rate between e.g. 47997 and say 48045 than it could easily starve the soundbuffer, thus resulting in sound synchronization problems. That would be my theory at least, for what it´s worth. Maybe I´m completely wrong about all this.

Quote
This is way beyond my knowledge of things, but it would be interesting to find if the PCI port, IRQs, etc. have some role to play here too, so that there could be some room for tweaking from the BIOS side.

It's also way beyond my knowledge. There's one thing that I noticed though: PCI and PCI-Express are two entirely different beasts from a hardware point of view, so don't get fooled by them sharing the PCI acronym. So where for PCI you could adjust the "PCI-Latency" timer value in the bios, thus configuring how many cycles each PCI device gets before handing over to the next device in the system, this is not the case anymore for PCI-Express. PCI-Express is packet based from what I understand, but what the implications are for soundcards and sound card drivers is way beyond my understanding.

I've been looking in the bios of my Asus P8Z77V (which *only* has PCI-Express slots) but there's seems nothing to configure anymore for PCI-related devices, apart from whether you'd want a specific video card slot to work at x16 or x8, which only seems relevant if you have a setup with more that one videocard.

Also I have to note that the XFi cards are giving me very good results (much better than DSound) with ASIO (via ASIO4ALL) in WinUAE, with no noticable difference stability wise with the realtek chip (apart from the XFi cards sounding richer to me).
Title: Re: Soundcard frequency stability test - please add your results
Post by: SMMM on November 05, 2013, 10:10:08 pm
Related question: What determines the refresh rate stability?  Is it the video card or the display itself?  What would the 'benefits' of having a more stable refresh rate be, if any?
Title: Re: Soundcard frequency stability test - please add your results
Post by: SMMM on November 11, 2013, 02:37:28 am
Is there a way we can introduce this test to a wider audience?  I'm about ready to pull the trigger on buying a soundcard for my project, but am uncomfortable doing so - having a larger sample size with more examples would be excellent.
Title: Re: Soundcard frequency stability test - please add your results
Post by: Dr.Venom on November 14, 2013, 05:24:11 am
Related question: What determines the refresh rate stability?  Is it the video card or the display itself?  What would the 'benefits' of having a more stable refresh rate be, if any?

I wouldn't worry about the refresh rate stability of your videocard / monitor, it's generally stable enough. If you do the math you'll see that any variation is in the nanoseconds per second, so it will take longer  for any possible deviation to accumulate to the stage where it would interfere with the emulation, then you are able to keep awake ;).

If there would be any sort of "problem" it's regarding the granularity of modern day video cards. They seem to work with multipliers that allow for high granularity, but not the infinite granularity that is needed to re-create the exact timings of all possible real arcade hardware. It comes very close in most cases (close enough to do "very accurate" emulation), but it's not perfect. Calamity called this a problem of A) Dotclock granularity and B) Dotclock uncertainty. If you're interested in some more technical background you can read more about it here: Theoretical versus real refresh rates (http://forum.arcadecontrols.com/index.php/topic,129585.msg1325567.html#msg1325567)

Is there a way we can introduce this test to a wider audience?  I'm about ready to pull the trigger on buying a soundcard for my project, but am uncomfortable doing so - having a larger sample size with more examples would be excellent.

Yes, basically we would need some other people to confirm Krick's results for the "PCI Sound Blaster X-Fi XtremeGamer", and generally get more conformation from other users on the already tested cards in the table. Hopefully some more people will add their results.

That said, I think we should keep in mind that we don't know the exact cause for the variation, and it may well have to do with how the DirectSound API is routed in Windows. There are much better APIs out there these days, like X-Audio2, WASAPI-EX and ASIO, which all are able to provide audio with much lower lag than DSound and as such would be better suited to (Groovy)MAME. The exclusive mode API's are even able to get close to realtime audio, whereas DSOUND isn't able to get better than something in the range of ~ 3 frames of lag (if not worse). Once a move in the direction of these new APIs is taken, I would't be surprised if the results for all tested soundcards would be quite different. (Of course we would also need an updated FreqTest tool to work with the new APIs). But until then, I think it will be anybody's guess... As such any educated guesses on this topic are still welcome :)
Title: Re: Soundcard frequency stability test - please add your results
Post by: Zagi on January 14, 2014, 09:52:37 pm
Is it proven the frequency stability have an impact on the latency ? I know this is about mame but in the built in ggpo emulator (fba) I can only set the sound buffer down to 3 frames without cracking with the Sound Blaster Live CT4760 which is not the most stable card I have tested.

I can also attest that the whole configuration may have an impact on the latency, as with my old rig for my cab (DFI nf4 ultra-d, opteron 165, 2gb of DDR1) I could lower the latency to 3 frames on the audigy 2 value, but I can't go below 4 frames with the new one (Asus p5kc, Q6600, 4gb of DDR3)

Anyway here are my results :

ALC883 XP64
ALC892 8.1 64
Sound Blaster Live CT4760 XP64
Audigy 2 Value XP64


Title: Re: Soundcard frequency stability test - please add your results
Post by: boganslogan on June 12, 2014, 09:53:09 am
I just tested my Creative Soundblaster Titanium HD in Windows 7 x64 and I got wonky results. I run an optical cable using DTS Connect from my sound card to my Logitech Z-5500 control panel. Unlike the other X-Fi or Soundblaster audio tests people submitted, I tested each of the 3 modes: Game, Audio Creation, and Entertainment. Audio Creation Mode is supposed to be the lowest latency with bit-matched playback and recording. I'm going to just leave the file names as-is which will tell you what I enabled or disabled with each test.

The wonky part is test #2 and test #7 had the exact same settings but I got different results, so that's why I think something's amiss.
Title: Re: Soundcard frequency stability test - please add your results
Post by: machyavel on June 12, 2014, 02:51:43 pm
W7x64, PCI card ESI JULI@:
Title: Re: Soundcard frequency stability test - please add your results
Post by: vicosku on June 18, 2014, 12:08:46 pm
Here are my results, from worst to best.  The venerable $30 USB Behringer UCA202 (http://nwavguy.blogspot.com/2011/02/behringer-uca202-review.html) performed well, as I expected.  All tests were performed on the same machine running XP64.

Realtek ALC888 | Onboard
Asus Xonar DG | PCI
HDE CMedia | USB
Turtle Beach Audio Advantage Micro II | USB
Behringer UCA202 | USB

Title: Re: Soundcard frequency stability test - please add your results
Post by: vicosku on June 20, 2014, 11:25:59 am
Here are the log results from running for at least 20 minutes for multiple sound cards with the default audio latency setting of 2.  These results seem to confirm Dr. Venom's statement that buffer overflows decrease the better your resampling frequency stability is. I've added an HDMI output as my most stable option and the one closest to the target frequency (Freqtest results attached).  The game run was garou at Frame_Delay 7.

Realtek ALC888
Average speed: 99.92% (1297 seconds)
Sound: buffer overflows=51 underflows=1
Average time between overflows: 25.43 seconds

Turtle Beach Audio Advantage Micro II
Average speed: 99.91% (1515 seconds)
Sound: buffer overflows=39 underflows=0
Average time between overflows: 38.85 seconds

Behringer UCA202
Average speed: 99.91% (2941 seconds)
Sound: buffer overflows=74 underflows=4
Average time between overflows: 39.74 seconds

ATI 4550 HDMI
Average speed: 99.91% (1424 seconds)
Sound: buffer overflows=31 underflows=0
Average time between overflows: 45.94 seconds

However, I can't seem to reach 0 overflows over 20-30 minutes at audio latency 2 or less regardless of other settings.  Even if I set the frame delay setting to 1 on this game I can run at 700% speed, the overflows are only reduced, not eliminated.

Turtle Beach Audio Advantage Micro II - Frame_Delay 1
Average speed: 99.92% (1281 seconds)
Sound: buffer overflows=22 underflows=2
Average time between overflows: 58.22 seconds

I suppose I must have some other issue.  I do wonder if it matters how close you are to the target of 48000 rather than the stability alone.  My UCA202 and ATI HDMI FreqTest results are just about as stable as each other, but the the HDMI result is closer to the target 48000 and produces slightly fewer buffer overflows.  I don't really have much to base this idea on, but I don't have any others at the moment.  Here are the settings and specs of the system used:

Mame64 -mt (Results were basically the same with multithreading on or off)
Frame_delay 7
Priority 1
Sleep 0

XP 64
Core2Duo e6600 2.4GHZ OC'd to 3.4GHZ
4GB RAM
Abit IP35-E
ATI 4550 PCI-E
Title: Re: Soundcard frequency stability test - please add your results
Post by: Dr.Venom on June 21, 2014, 10:52:08 am
Hi,

First off, thanks to all who have been posting their results in this thread.

@vicosku
Thanks for the detailed results vicosku, much appreciated.

You're correct in your guess about the 48000 target being important. It's not stability in itself, but stability in terms of how close the min-max values are to that target of 48000. The results table in the first post is also based on that principle:

absolute(max-48000)
absolute(min-48000)
--------------------------- +
total absolute deviation

The lower this total absolute deviation the better the result (and ranking in the table), ideally this value is 0. You're quite possibly right about your suspicion that something isn't right in your system, since your results show a systematic deviation from the target 48000, even when the min-max values in itself are close to eachother. Given that you have a core2duo and are on XP, possibly your system is affected by either one of these problems with the system timer:

Performance counter value may unexpectedly leap forward:
http://support.microsoft.com/kb/274323/en-gb (http://support.microsoft.com/kb/274323/en-gb)
Programs that use the QueryPerformanceCounter function may perform poorly in Windows Server 2000, in Windows Server 2003, and in Windows XP
http://support.microsoft.com/kb/895980 (http://support.microsoft.com/kb/895980)

But ofcourse it could also be something completely different... Welcome to the wonderful world of PC's ;)


@boganslogan

I just tested my Creative Soundblaster Titanium HD in Windows 7 x64 and I got wonky results.

I've had this same experience with my PCI-Express soundcards in Windows 7. To be honest, it has seriously been bugging me for months why PCI-Express cards are giving such unreliable/unstable results, especially when on-board audio in the same system would return stable results.

I'm very glad to say that I've finally tracked the issue, for my system at least, but hopefully for others also. The HPET hardware timer is the big culprit. After disabling it in the BIOS, I'm getting rock-steady and accurate results with the PCI-Express audiocards. Interestingly it even further improves the results for the on-board audio.

As always once you get a red car yourself, you suddenly see lots of other red cars on the road. So I stumbled upon this page:

"Acquiring high-resolution time stamps" (http://msdn.microsoft.com/en-us/library/windows/desktop/dn553408%28v=vs.85%29.aspx (http://msdn.microsoft.com/en-us/library/windows/desktop/dn553408%28v=vs.85%29.aspx))

Which makes it clear that the HPET timer is by far inferior to TSC's, because of its much larger system overhead:
Quote
Windows 7 and Windows Server 2008 R2

The majority of Windows 7 and Windows Server 2008 R2 computers have processors with constant-rate TSCs and use these counters as the basis for QPC. TSCs are high-resolution per-processor hardware counters that can be accessed with very low latency and overhead (in the order of 10s or 100s of machine cycles, depending on the processor type). Windows 7 and Windows Server 2008 R2 use TSCs as the basis of QPC on single-clock domain systems where the operating system (or the hypervisor) is able to tightly synchronize the individual TSCs across all processors during system initialization.On such systems, the cost of reading the performance counter is significantly lower compared to systems that use a platform counter. Furthermore, there is no added overhead for concurrent calls and user-mode queries often bypass system calls, which further reduces overhead. On systems where the TSC is not suitable for timekeeping, Windows automatically selects a platform counter (either the HPET timer or the ACPI PM timer) as the basis for QPC.

So after all, now I understand why Microsoft is by default disabling the HPET in software in Windows 7, even if it's enabled in the BIOS. I probably shouldn't have enabled it by force through the bcedit command, thinking the HPET at 14Mhz would work better.

In any case, if you're are getting wonky/unstable results with PCI-Express soundcards and have the HPET counter enabled in your BIOS, you may want to try and disable it, and see what results you get afterwards. It may or may not make a big difference. My PC is build on an Asus P8Z77-V Deluxe mainboard, and the setting can be found in the Advanced Menu --> PCH Configuration

(http://i61.tinypic.com/o6w7j6.png)

Given this I'm inclined to think that the Frequency test is both a combined test of the actual soundcard frequency stability, but at the same time also a test of the reliability of the system counter that QPC uses. Since both are important to MAME, I guess in the end it doesn't matter, but still one to keep in mind.

Title: Re: Soundcard frequency stability test - please add your results
Post by: cools on June 22, 2014, 10:14:35 am
Realtek ALC887, Windows 7, Microsoft standard driver, HPET off.

Title: Re: Soundcard frequency stability test - please add your results
Post by: Dr.Venom on June 27, 2014, 02:43:34 pm
Hi,

I've been doing some more testing, which confirms the link between the platform timer that is used and sound stability. A reduction by a factor of ten for the amount of overflows is shown in the example below.

The timing in MAME uses a function QueryPerformancecCounter/Frequency that depends on the platformtimer in the computer (CPU and/or motherboard). There have been various types of timers evolving over the years, leading to a situation where Windows has a choice from various hardware timers in a PC. Such as HPET, TSC's, LAPIC's or a combination. Windows has some intelligent decision making baked in the OS to decide which is best for the specific combination of hardware and OS.

In my previous post I stated that when the High Precision Event Timer (HPET) is enabled in the BIOS, together with the useplatformclock set to TRUE in Windows, I may experience erratic results with the FreqTest tool in combination with PCI-Express audio cards. Just as some of the other users have reported.

Now I found out another interesting thing. When I disable the HPET in the BIOS, BUT set Windows 7 to use the platformclock, then *another* hardware timer is used! So for my system there are three possibilities:

1.Bios HPET ON & W7 useplatformclock=TRUE
2.Bios HPET OFF & W7 useplatformclock=TRUE
3.Bios HPET OFF & W7 useplatformclock=FALSE

1= HPET = 14.31818Mhz
2= LAPICs = 3.57955Mhz
3= TSC+LAPICs = 3.41806Mhz

Earlier I reported on the erratic results that came up with setting 1 (in hindsight the main reason for starting this thread). So I'll not focus any further on that. Instead, I have now done a more extensive test for 2 and 3. Both provide stable results in Freqtest, although 2 being slightly better than 3 (see attached pictures). Next up is a more extensive run in GroovyMAME. Note that in this test I have been running the MESS MSX2 driver vsynced at audio latency setting of 1.0(!), with framedelay at 7, each for half an hour.

2.Bios HPET OFF & W7 useplatformclock=TRUE (3.57955Mhz)

Average speed: 100.00% (1883 seconds)
Sound: buffer overflows=2 underflows=1
Average time between overflows: 941 seconds

3.Bios HPET OFF & W7 useplatformclock=FALSE (3.41806Mhz)

Average speed: 100.00% (1831 seconds)
Sound: buffer overflows=22 underflows=1
Average time between overflows: 83 seconds

The bottomline:
The results speak for itself, it makes a material difference for GroovyMAME what hardware counter is used as default in Windows. When Windows is set to use the counter in option 3, GroovyMAME runs at about ten times as many overflows. With option 2 it runs near perfect. Interestingly in a default setup where HPET is off in the BIOS, Windows7 will default to option 3, the worse of the two.

If you want to test for yourself, you can try between all four combinations*  of A) enabling/disabling HPET in your BIOS and B) enabling/disabling the useplatformclock in Windows. In Windows 7 you can set the useplatformclock to true or false by running a CMD shell with admin privileges and then do:

"bcdedit /set useplatformclock true" to enable the HPET (when enabled in the BIOS) or some other platformclock (when HPET disabled in the BIOS)
"bcdedit /deletevalue useplatformclock" to set it to false

* Note: for me there are three different results as HPET ON and platformclock false gives the same result as 3 for me.

After doing a change a reboot is required for the new settings to take effect. Download the tool WinTimerTester (here: http://www.mediafire.com/?xzo9n84d8lze9nb (http://www.mediafire.com/?xzo9n84d8lze9nb)) to check what timer frequency is used for QPF. Only look at the Mhz number at the top of the window, disregard the rest. After each reboot and verification with WinTimerTester that the QPF value is different, you could run FrequencyTest and additionally do a GroovyMAME test comparable to mine. That should give you an idea on which timer is best for your system.

Of course as always, the usual disclaimers apply: for some this may make a difference, but for others it may do nothing. As the saying goes, if it ain't broke, don't fix it :)
Title: Re: Soundcard frequency stability test - please add your results
Post by: vicosku on June 28, 2014, 12:00:06 pm
Dr. Venom, thank you very much for all this information.  My results under XP64 with /usepmtimer are very similar to your Windows 7 results.  The Wintimertester reported a weird result on this computer by default - 2993 Mhz, which is the same as the total clock speed.  The result on my other computers was the clock speed divided by 1024, but whatever.  The /usepmtimer switch gave me the same 3.57955Mhz result you reported.  I've attached pictures of the frequency test result of my Onboard ADI Soundmax audio under both conditions.  Games that I can run reliably at 100% now give very few buffer issues at an audio latency setting of 1.  Terra Cresta at Frame_Delay 9 gave 9 buffer overflows after 30 minutes, for example.  Newer games that run just under 100% have more overflows, of course.  I suppose now all I need is to invest in as much CPU power as possible.

Title: Re: Soundcard frequency stability test - please add your results
Post by: Paradroid on June 29, 2014, 02:59:35 am
I've been doing some more testing, which confirms the link between the platform timer that is used and sound stability.

Fascinating report! Thanks for digging deeper and sharing your finding.

I'm yet to conduct the stability tests on my own hardware but I'm interested to see the results I get...
Title: Re: Soundcard frequency stability test - please add your results
Post by: Dr.Venom on June 29, 2014, 08:23:46 am
Dr. Venom, thank you very much for all this information.  My results under XP64 with /usepmtimer are very similar to your Windows 7 results.

Thanks for reporting. Good to know that this can have comparable impact on XP also. Out of interest, what hardware platform did you get this result on (motherboard/cpu)? Was it the Core2Duo e6600 2.4GHZ OC'd to 3.4GHZ on Abit IP35-E you reported earlier or something different?

Fascinating report! Thanks for digging deeper and sharing your finding.

I'm yet to conduct the stability tests on my own hardware but I'm interested to see the results I get...

My pleasure, it's also been fascinating to (slowly) uncover the real issue. Will be interesting to see whether or not it will have an impact on your setup also.
Title: Re: Soundcard frequency stability test - please add your results
Post by: vicosku on June 29, 2014, 09:32:06 am

Thanks for reporting. Good to know that this can have comparable impact on XP also. Out of interest, what hardware platform did you get this result on (motherboard/cpu)? Was it the Core2Duo e6600 2.4GHZ OC'd to 3.4GHZ on Abit IP35-E you reported earlier or something different?


No problem.  This was a different machine - a Dell Optiplex 755 with a Core2Duo Conroe e6850 3 GHZ CPU and an ATI HD4550.  I switched the other machine back to its previous Windows 7 HTPC duties.
Title: Re: Soundcard frequency stability test - please add your results
Post by: Dr.Venom on June 29, 2014, 10:22:25 am
It's at least a dual core I see. I have a strong feeling that the "unreliable" timers are using the Timer Stamp Counters (TSCs) in the CPUs, and what we may be experiencing is a phenomenon called timer drift (in this case "TSC drift"). The alternative timer that we switch to from within the OS, apparently does not suffer from this problem.

There's some documentation here: CPU Cycle Counter (TSC) (https://software.intel.com/sites/products/documentation/hpc/ics/itac/81/ITC_Reference_Guide/CPU_Cycle_Counter_%28TSC%29.htm) and here: Beware of QueryPerformanceCounter() (http://www.virtualdub.org/blog/pivot/entry.php?id=106).

The latter which I already posted about in the Input Lag thread. Now it starts to make sense why we should probably add an option to use TimeGetTime() as an alternative to the QPC/QPF method in GroovyMAME, as discussed back then. My hunch is that the TimeGetTime() routine most probably bypasses that TSC counter, but goes for the more reliable one instead directly? But I could be wrong...

Calamity, are you reading this? ;)



Edit: just some other interesting links for reference:
What’s the difference between GetTickCount and timeGetTime? (http://blogs.msdn.com/b/larryosterman/archive/2009/09/02/what-s-the-difference-between-gettickcount-and-timegettime.aspx)
QueryPerformance counter in multicore systems with variable clock speeds (http://stackoverflow.com/questions/14363398/queryperformance-counter-in-multicore-systems-with-variable-clock-speeds), especially the last post, which is interesting enough to quote here:

Quote
But you're not necessarily asking the right questions...

The four commonly used timing functions are: GetTickCount, timeGetTime, QueryPerformanceCounter (QPC), and RDTSC

My recommendations among those:

Game logic timing should be done with timeGetTime. It is simple, reliable, and has sufficient resolution for that purpose.

GetTickCount should not be used. It's resolution is too poor for either game logic or performance monitoring (64 Hertz - a nasty frequency as it creates a beat frequency with the typical monitor refresh rate). It is the fastest timing function call IIRC, but I can't find a scenario in which that makes up for its poor resolution.

RDTSC & QPC are both too unreliable / quirky for simple game logic timing, but better suited for performance measurements. RDTSC has issues that make it painful to use if you want units independent of CPU frequency changes, and you usually need asm to use it. QPC usually just works... but when it goes wrong it can go very wrong, and it goes wrong in a very wide variety of ways (sometimes it's really slow, sometimes it has frequent small negative deltas, sometimes it has infrequent large negative deltas (not wrap-arounds), sometimes it's just completely psychotic, etc). RDTSC is pretty much always faster, and usually significantly better resolution. Overall I prefer RDTSC for in-house use just because it is faster and thus produces fewer distortions in the times its measuring. On customers machines, it's a much closer call - QPC is easier to justify due to Microsoft pushing it, and it works without complications more often, but the wide variety of ways it can screw up on customer machines that you'll never see in-house is a major drawback in my view.
Title: Re: Soundcard frequency stability test - please add your results
Post by: vicosku on June 29, 2014, 12:12:08 pm
This is probably information that you are already aware of, but I want to make sure.  Check footnote 4 on the HPET Wikipedia page.  It's pretty long, so I'll just copy a small excerpt here. 

http://en.wikipedia.org/wiki/High_Precision_Event_Timer (http://en.wikipedia.org/wiki/High_Precision_Event_Timer)

Quote
The early multi-core CPUs from AMD exposed a problem with TSC-derived QueryPerformanceCounter readings, as they would be affected by spread-spectrum and power management speed variations. While this was eventually solved in later processor designs by making the TSC clock independent of the CPU clock, the PM Timer on ACPI systems became the counter source of choice, requiring a /USEPMTIMER override in the Windows BOOT.INI file to enforce its use. On both Intel and AMD machines using the ACPI HAL together with the /USEPMTIMER boot switch, the IRQs 0 & 8 will still report a HPET, but now the QueryPerformanceFrequency will report 3.579545 MHz, which is the frequency of the PMTIMER. This has the express advantage of being independent of the CPU frequency and still provides a very reasonable sub-microsecond resolution and accuracy. Ironically the very high count rates obtained in TSC mechanisms (as compared with PMTIMER or the Intel HPET device) can cause a problem that the measurable time intervals are too short: there is an upper limit to the usefulness of a counter that overflows early.
Title: Re: Soundcard frequency stability test - please add your results
Post by: Dr.Venom on June 29, 2014, 05:26:05 pm
This is probably information that you are already aware of, but I want to make sure.  Check footnote 4 on the HPET Wikipedia page.  It's pretty long, so I'll just copy a small excerpt here.

I had read the wiki on HPET, but not the interesting footnote. Thanks for pointing that out.

Title: Re: Soundcard frequency stability test - please add your results
Post by: elvis on June 29, 2014, 11:07:05 pm
Interested to help out, but I only have access to Linux machines.

Is there either a similar test for Linux, and/or is it worthwhile me submitting runs from WINE?  Or would these just confuse the issue?
Title: Re: Soundcard frequency stability test - please add your results
Post by: Doozer on June 30, 2014, 03:39:30 am
[deleted]
Title: Re: Soundcard frequency stability test - please add your results
Post by: Dr.Venom on July 02, 2014, 04:37:59 pm
Interested to help out, but I only have access to Linux machines.

Is there either a similar test for Linux, and/or is it worthwhile me submitting runs from WINE?  Or would these just confuse the issue?

I'm not aware of a similar test for Linux, but if you would find one it's best to start a new topic on the matter.
Title: Re: Soundcard frequency stability test - please add your results
Post by: Dr.Venom on August 09, 2014, 03:49:04 am
For those who are interested. I found that not all -new- motherboards give you access to enabling or disabling the HPET in the BIOS. This means that for those motherboards that HPET cannot be disabled, you cannot in Windows 7 enable the PM Timer as the hardware platform timer (as previously discussed), and be stuck with the combination of TSC and HPET. Consequently, you may not be running the most reliable hardware timer.

So a word of advice. If you are looking to build a new system based on newest hardware, and combine it with Windows 7, look up the online manual of the motherboard first. These are easy to find online, and see if the manual mentions an option to enable or disable the HPET (High Precision Event Timer) in the BIOS.

As an example that got me a bit surprised. The brand newAsus Z97 Deluxe (http://www.asus.com/Motherboards/Z97DELUXE/)  motherboard will not allow you to change this setting, it has HPET always enabled. I seriously can't believe this omission, given the amount of discussion on the HPET topic on internet. While from the same manufacturer, the brand new MAXIMUS VII Hero (http://www.asus.com/Motherboards/MAXIMUS_VII_HERO/) does have an option in the BIOS to enable/disable it.  From what I've seen new MSI boards all provide an option in the bios to configure it.

I'm rather surprised that from the same manufacturer, motherboards of the same generation may use different implementations. I guess I got lucky when I got my Asus P8Z77V-Deluxe, as otherwise I would have never found out about how these different timers impact emulation accuracy.

Anyway, maybe this is of help to some.
Title: Re: Soundcard frequency stability test - please add your results
Post by: vicosku on August 09, 2014, 09:18:27 am
Thanks.  I noticed this as well.  My computers are all a few to several years old, and none of them have the option to disable HPET in BIOS.  I set up GroovyMame on one of them in Windows 7 and was disappointed that I couldn't use the pmtimer.  However, running Windows XP on this same machine with /usepmtimer in boot.ini allows me to use it, so not all is lost. 

By the way, thanks again for this topic and your findings.  I can run just about any game with an audio latency of 1.0 these days and no audible issues. 
Title: Re: Soundcard frequency stability test - please add your results
Post by: Dr.Venom on August 10, 2014, 05:45:09 am
Thanks, it's been my pleasure to find out. All the better that it's been of help to you/others also.

It will be interesting though to see how these things play out for Windows 8.1 and up. From what I read Microsoft is still using the TSC timer as default in Win 8, but apparently they've made changes to timer synchronization during boot, so -maybe- that'll change things for the better. If not, then the big question mark will be whether the current method for enabling the PM Timer in Win 7 will still be possible for Win 8.1+.

There are some hurdles to take before getting there though, not the least getting Calamity enthusiastic for acquiring a Win 8 code signing certificate for CRT_Emudriver. And even then I'm not sure whether there'll be any advantage to using Win 8.1 over Win 7 for a GroovyMAME setup, apart from the Microsoft support for the OS ending in 2023 instead of 2020...

I guess if at some point CRT_Emudriver would get Win 8.1 support, either me or someone else will be mad enough to test it, so let's keep some space reserved here ;)
Title: Re: Soundcard frequency stability test - please add your results
Post by: krick on August 10, 2014, 01:03:17 pm
@Dr. Venom

Have you seen this thread?...
http://www.neowin.net/forum/topic/1075781-tweak-enable-hpet-in-bios-and-os-for-better-performance-and-fps/ (http://www.neowin.net/forum/topic/1075781-tweak-enable-hpet-in-bios-and-os-for-better-performance-and-fps/)

The original poster seems obsessed with having HPET on.
There's lots of good info in the thread, especially as it gets more pages in and there's more dissenters.

Of possible interest is this "Invariant TSC" bit mentioned near the end..

Quote
    17.13.1 Invariant TSC

    The time stamp counter in newer processors may support an enhancement, referred to as invariant TSC.
    Processor’s support for invariant TSC is indicated by CPUID.80000007H:EDX[8].
     
    The invariant TSC will run at a constant rate in all ACPI P-, C-. and T-states. This is the architectural behavior
    moving forward. On processors with invariant TSC support, the OS may use the TSC for wall clock timer services
    (instead of ACPI or HPET timers). TSC reads are much more efficient and do not incur the overhead associated with

    a ring transition or access to a platform resource.
     
    --

    http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-3b-part-2-manual.html (http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-3b-part-2-manual.html)
Title: Re: Soundcard frequency stability test - please add your results
Post by: adder on August 11, 2014, 07:32:31 am
ADI SOUNDMAX 1984 HD AUDIO -  47979.146  47979.252  47979.361  - ON BOARD - XP64
CONEXANT HD AUDIO VENICE 5045 -  47999.797  47999.893  47999.969  - ON BOARD - XP32