Soundcard frequency stability test - please add your results

[vicosku]

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

[Dr.Venom]

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

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)

Which makes it clear that the HPET timer is by far inferior to TSC's, because of its much larger system overhead:

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



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.

[cools]

Realtek ALC887, Windows 7, Microsoft standard driver, HPET off.

[Dr.Venom]

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

[vicosku]

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.

[Paradroid]

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

[Dr.Venom]

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.

[vicosku]

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.

[Dr.Venom]

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) and here: Beware of QueryPerformanceCounter().

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?
QueryPerformance counter in multicore systems with variable clock speeds, especially the last post, which is interesting enough to quote here:

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.

[vicosku]

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

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.

[Dr.Venom]

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.

[elvis]

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?

[Doozer]

[deleted]

[Dr.Venom]

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.

[Dr.Venom]

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

[vicosku]

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. 

[Dr.Venom]

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

[krick]

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

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

    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

[adder]

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