Card | Min (Hz) | Avg (Hz) | Max (Hz) | OS | Interface | User |
Realtek ALC861 | 48000,018 | 48000,030 | 48000,080 | Vista x64 | On-board | SMMM |
Sound Blaster X-Fi XtremeGamer | 47998,995 | 47999,05 | 47999,099 | XP x64 | PCI | Krick |
Auzentech X-Fi Prelude 7.1 | 47998,720 | 47998,810 | 47998,897 | XP x86 | PCI | Goglu2 |
Realtek ALC269 | 47998,298 | 47998,676 | 47998,934 | W7 x64 | On-board | Calamity |
Nvidia 550Ti (HDMI out) | 47998,440 | 47998,456 | 47998,472 | W7 x64 | PCI Express | SMMM |
SIGMATEL STAC 92XX C-Major HD Audio | 47998,200 | 47998,244 | 47998,275 | W7 x64 | On-board | Calamity |
Realtek ALC892 | 47997,946 | 47998,002 | 47998,054 | W7 x64 | On-board | bulbousbeard |
Realtek ALC887 | 47997,927 | 47997,951 | 47997,971 | W7 x64 | On-board | Krick |
Realtek ALC850 | 47997,934 | 47997,941 | 47997,959 | W7 x64 | On-board | deathterrapin |
Realtek ALC898 | 47997,252 | 47997,262 | 47997,292 | W7 x64 | On-board | Dr.Venom |
SIGMATEL STAC 92XX C-Major HD Audio | 48008,415 | 48008,485 | 48008,574 | XP x64 | On-board | Calamity |
Realtek ALC662 | 47973,221 | 47976,507 | 47993,630 | XP x64 | On-board | Calamity |
C-Media USB CM106 | 47997,932 | 48002,742 | 48045,940 | W7 x64 | USB | deathterrapin |
VIA VT1828S | 47997,245 | 48002,060 | 48045,268 | W7 x64 | On-Board | SMMM |
Auzentech X-Fi Forte | 47997,232 | 48002,057 | 48045,257 | W7 x64 | PCI Express | Dr.Venom |
C-Media USB unknown (0D8C 000E) | 47973,471 | 47975,037 | 47978,460 | XP x64 | USB | deathterrapin |
C-Media USB CM106 | 47973,478 | 47974,899 | 47978,343 | XP x64 | USB | deathterrapin |
Realtek ALC889 | 47950,417 | 47993,645 | 47998,486 | W7 x64 | On-Board | SMMM |
Creative SB X-Fi | 47949,261 | 48006,380 | 48045,260 | W7 x64 | PCI Express | Dr.Venom |
Asus Xonar DG | 47949,252 | 48006,863 | 48093,336 | W7 x64 | PCI | SMMM |
Realtek ALC889a | 47873,472 | 47946,747 | 48026,595 | W7 x64 | On-board | JDFan |
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.
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.
BTW the FreqTest program doesn't work under Win32.
@ JDFan: What OS are you using? If it's W7, did you apply step 1, as described in the first post?
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 --
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.
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.
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.
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
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.
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.
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?
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.
I just tested my Creative Soundblaster Titanium HD in Windows 7 x64 and I got wonky results.
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.
I've been doing some more testing, which confirms the link between the platform timer that is used and sound stability.
Dr. Venom, thank you very much for all this information. My results under XP64 with /usepmtimer are very similar to your Windows 7 results.
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...
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?
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.
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.
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.
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?
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)