This is the place for you to find more detailed technical information and special details about our products.
Additionally, you will find detailed explanations on various subjects, which didn't fit into the manuals.

Fahlens Corner

Notes on the Complexity of Measuring True Performance Differences with DAW Stress Tests

Different DAW stress tests & configurations will not throttle your system in the same way

The original and Thonex II stress tests are known to throttle the DAW system harder (specifically in terms of
VSTi/sample capacity) than e.g. the Sonar 3 test which should be taken into consideration. Case in point - the
nForce4 with a single-core AMD 64 cpu may not act differently than other DAWs lacking the PCI-PCIe interconnectivity
issue under light stress (Sonar 3, Five Tower), whereas performance differences start to become real when the PCI bus
is throttled harder (Thonex, Thonex II).

Even different versions of drivers, DAW software and VSTIs will yield different stress test data - other variables
kept constant. Thonex stress test data based on Nuendo 2 generally results in lower CPU loads than if based on the
Nuendo 3.x version - all other factors kept constant. Different host software versions, as well as unstable systems,
are known to yield varying or inconsistent CPU read off results and thus likely to cause skewed interpretations of
the actual variable to be tested.

Stress test results will primarily mirror the mode of the test design itself and thus vary across different test
platforms. From a user perspective, the important thing is to identify a test design which is a relevant reflection
of real-world conditions likely to represent your DAW work (i.e. are you a hard hitter dependent on hundreds of audio
tracks including a multitude of VSTi/samples, or rather dealing with multimedia work based on a limited number of
audio/midi tracks ?).

Host/menu read-off latency vs. true latency in audio stress tests

When comparing DAW stress test data across various soundcards used, the reader should interpret any performance
differences at a specific buffer setting cautiously as the soundcard's menu latency setting may not reflect real I/O
latency values. The German magazine, Keyboard (04/2005), measured the latency performance differences on seven
Firewire soundcards and concluded that the discrepancies between indicated software latency values and real roundtrip
latency ranged from 0 ms up to 7.1 ms. The RME Fireface 800 was the only tested device that did not differ (software
indicated vs. real roundtrip values).

It is also important to note that Firewire soundcard interfaces usually include additional safety buffer latency in
playback mode compared to PCI soundcards (this is needed as Firewire devices lack Direct Memory Access, DMA, as PCI
devices). Thus, when comparing audio stress test data using playback mode with e.g. the RME Fireface it will add 64
samples latency via its safety buffer. If all other variables are kept constant the effective playback latency, RME
HDSP PCI vs. RME Fireface 800, would actually add 1.5 ms (64 samples) at 44.1 kHz in the latter case. This effect is
illustrated in the following figures:

CPU frequency and memory bandwidth/timings have significant impacts on audio stress test results - keeping other
variables constant. The performance difference usually increases as latency setting values become smaller as
illustrated by the following graphs:

Figure 3. Influence of CPU frequency on CPU load (%) as measured by the Sonar 3 test. All other
BIOS/Host software settings and hardware configurations kept constant. Input data based on
user reports submitted to the Sonar forum.

Figure 4. Influence of memory timings on CPU load (%) as measured by the Sonar 3 test. All other
BIOS/Software settings and hardware configuration kept constant. Input data based on user
reports submitted to the Sonar forum.

Figure 6. Influence of memory timings & bandwidth (1T vs. 2T command rate) on average number of
Magneto plugins able to play (1 st test run without reload) as a function of latency
settings. Input data based on user reports submitted to the Nuendo Hardware forum.

One of the conclusions made from the graphs presented (figures 4 and 6) is that memory timings and bandwidth have a
comparatively larger influence on performance in low latency DAW work than in most other software usages. This
indicates that in cases where the CPU-memory sub-systems are stressed there is a real-world advantage of being able
to tweak memory performance and using memory modules capable of tight memory settings. Among adjustable parameters
influencing memory timings and bandwidth, the command rate (or clock per cycle, CPC), which regulates how system
clocks are allocating timings of a command to the system, is likely to have the greatest partial impact (disregarding
the potential impacts of NUMA and 32-bit/64-bit NUMA OS support with Opteron CPUs). Users with AMD 64/X2/Opteron CPUs
having high-demands on performance at low latencies may want to verify if their combination of memory, BIOS and
mainboard is capable of running at 1T command rate instead of the default value (2T). Such a tweak must though be
verified to run stable over time.

Acknowledgements

Many thanks to Andrew K ("Thonex") who developed the Thonex original and Thonex II stress tests for Cubase/Nuendo, Vin
Curigliano ("Tafkat") who developed and conducted the Blofelds DSP40 DAW stress test, Scott Reams who developed the
Sonar 3 stress test, and ADK Pro Audio ("jschild") who has publicly submitted numerous DAW stress test results.
Likewise, without users publicly giving feedback and details on public forum about their DAW stress test results the
audio community would be weaker in knowledge than presently found. Kudos to all involved!