Optimization for lowest Audio Latency

Started by admin, November 11, 2014, 10:14:08 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

admin

http://www.harmonycentral.com/articles/all-about-computers-and-audio-latency

Meet the ghost in your machine

By Craig Anderton

Musicians are used to an instant response: Hit a string, hit a key, strike a drum, or blow into a wind instrument, and you hear a sound. This is true even if you're going through a string of analog processors.

But if you play through a digital signal processor, like a digital multieffects, there will be a very slight delay called latency—so small that you probably won't notice it, but it's there. Converting an analog signal to digital takes about 600 microseconds at 44.1kHz; converting back into analog takes approximately the same amount, for a "round trip" latency of about 1.2 milliseconds. There may also be a slight delay due to processing time within the processor.

Because sound travels at about 1 foot (30 cm) per millisecond, the delay of doing analog/digital/analog conversion is about the same as if you moved a little over a foot away from a speaker, which isn't a problem. However, with computers, there's much more going on. In addition to converting your "analog world" signal to digital data, pieces of software called drivers have the job of taking the data generated by an analog-to-digital converter and inserting it into the computer's data stream. Furthermore, the computer introduces delays as well. Even the most powerful processor can do only so many millions of calculations per second; when it's busy scanning its keyboard and mouse, checking its ports, moving data in and out of RAM, sending out video data, and more, you can understand why it sometimes has a hard time keeping up.

As a result, the computer places some of the incoming audio from your guitar, voice, keyboard, or other signal source in a buffer, which is like a "savings account" for your input signal. When the computer is so busy elsewhere that it can't deal with audio, it makes a "withdrawal" from the buffer instead so it can go deal with other things. The larger the buffer, the less likely the computer will run out of audio data when it needs it. But a larger buffer also means that your instrument's signal is being diverted for a longer period of time before being processed by the computer, which increases latency. When the computer goes to retrieve some audio and there's nothing in the buffer, audio performance suffers in a variety of ways: You may hear stuttering, crackling, "dropouts" where there is no audio, or worse case, the program might crash.

The practical result of latency is that if you listen to what's you're playing after it goes through the computer, you'll feel like you're playing through a delay line, set for processed sound only. If the delay is under 5 ms, you probably won't care too much. But some systems can exhibit latencies of tens or even hundreds of milliseconds, which can be extremely annoying.

Because you want the best possible "feel" when playing your instrument through a computer, let's investigate how to obtain the lowest possible latency, and what tradeoffs will allow for this.

MINIMIZING LATENCY

The first step in minimizing delay is the most expensive one: Upgrading your processor. When software synthesizers were first introduced, latencies in the hundreds of milliseconds were common. With today's multi-core processors and a quality audio interface, it's possible to obtain latencies well under 10 ms (and often less) at a 44.1kHz sampling rate.

The second step toward lower latency involves using the best possible drivers, as more efficient drivers reduce latency. Steinberg devised the first low-latency driver protocol specifically for audio, called ASIO (Advanced Streaming Input Output). This tied in closely with the CPU, bypassing various layers of both Mac and Windows operating systems. At that time the Mac used Sound Manager, and Windows used a variety of protocols, all of which were equally unsuited to musical needs. Audio interfaces that supported ASIO were essential for serious musical applications.

Eventually Apple and Microsoft realized the importance of low latency response and introduced new protocols. Microsoft's WDM and WASAPI in exclusive mode were far better than their previous efforts; starting with OS X Apple gave us Core Audio, which was tied in even more closely with low-level operating system elements. Either of these protocols can perform as well as ASIO. However for Windows, ASIO is so common and so much effort is put into developing ASIO drivers that most musicians select ASIO drivers for their interfaces.

So we should just use the lowest latency possible, yes? Well, that's not always obtainable, because lower latencies stress out your computer more. This is why most audio interfaces give you a choice of latency settings (Fig. 1), so you can trade off between lowest latency and computer performance. Note that latency is given either in milliseconds or samples; while milliseconds is more intuitive, the reality is that you set latency based on what works best (which we'll describe later, as well as the meaning behind the numbers). The numbers themselves aren't that significant other than indicating "more" or "less."




Fig. 1: Roland's VS-700 hardware is being set to 64 samples of latency in Cakewalk Sonar.

If all your computer has to do is run something like a guitar amp simulator in stand-alone mode, then you can select really low latency. But if you're running a complex digital audio recording program and playing back lots of tracks or using virtual software synthesizers, you may need to set the latency higher.

So, taking all this into account, here are some tips on how to get the best combination of low latency and high performance.

If you have a multi-core-based computer, check whether your host recording program supports multi-core processor operation. If available, you'll find this under preferences (newer programs are often "multiprocessor aware" so this option isn't needed). This will increase performance and reduce latency.
With Windows, download your audio interface's latest drivers. Check the manufacturer's web site periodically to see if new drivers are available, but set a System Restore point before installing them—just in case the new driver has some bug or incompatibility with your system. Macs typically don't need drivers as the audio interfaces hook directly into the CoreAudio services (Fig. 2), but there may be updated "control panel" software for your interface that provides greater functionality, such as letting you choose from a wider number of sample rates.


Fig. 2: MOTU's Digital Performer is being set up to work with a Core Audio device from Avid.

Make sure you choose the right audio driver protocol for your audio interface. For example, with Windows computers, a sound card might offer several possible driver protocols like ASIO, DirectX, MME, emulated ASIO, etc. Most audio interfaces include an ASIO driver written specifically for the audio interface, and that's the one you want to use. Typically, it will include the manufacturer's name.
There's a "sweet spot" for latency. Too high, and the system will seem unresponsive; too low, and you'll experience performance issues. I usually err on the side of being conservative rather than pushing the computer too hard.
Avoid placing too much stress on your computer's CPU. For example, the "track freeze" function in various recording programs lets you premix the sound of a software synthesizer to a hard disk track, which requires less power from your CPU than running the software synthesizer itself.

MEASURING LATENCY

So far, we've mostly talked about latency in terms of milliseconds. However, some manufacturers specify it in samples. This isn't quitebas easy to understand, but it's not hard to translate samples to milliseconds. This involves getting into some math, so if the following makes your brain explode, just remember the #1 rule of latency: Use the lowest setting that gives reliable audio operation. In other words, if the latency is expressed in milliseconds, use the lowest setting that works. If it's specified in samples, you still use the lowest setting that works. Okay, on to the math.

With a 44.1kHz sampling rate for digital audio (the rate used by CDs and many recording projects), there are 44,100 samples taken per second. Therefore, each sample is 1/44,100th of a second long, or about 0.023 ms. (If any math wizards happen to be reading this, the exact value is 0.022675736961451247165532879818594 ms. Now you know!)

So, if an audio interface has a latency of 256 samples, at 44.1 kHz that means a delay of 256 X 0.023 ms, which is about 5.8 ms. 128 samples of delay would be about 2.9 ms. At a sample rate of 88.2 kHz, each sample lasts half as long as a sample at 44.1 kHz, so each sample would be about 0.0125 ms. Thus, a delay of 256 samples at 88.2 kHz would be around 2.9 ms.

From this, it might seem that you'd want to record at higher sample rates to minimize latency, and that's sort of true. But again, there's a tradeoff because high sample rates stress out your computer more. So you might indeed have lower latency, but only be able to run, for example, half the number of plug-ins you normally can.

SNEAKY LATENCY ISSUES

Audio interfaces are supposed to report their latency back to the host program, so it can get a readout of the latency and compensate for this during the recording process. Think about it: If you're playing along with drums and hear a sound 6 ms late, and then it takes 6 ms for what you play to get recorded into your computer, then what you play will be delayed by 12 ms compared to what you're listening to. If the program knows this, it can compensate during the playback process so that overdubbed parts "line up" with the original track.

However, different interfaces have different ways to report latency. You might assume that a sound card with a latency of 5.8 milliseconds is outperforming one with a listed latency of 11.6 ms. But that's not necessarily true, because one might list the latency a signal experiences going into the computer ("one-way latency"), while another might give the "round-trip" latency—the input and output latency. Or, it might give both readings.

Furthermore, these readings are not always accurate. Some audio interfaces do not report latency accurately, and might be off by even hundreds of samples. So, understand that if an audio interface claims that its latency is lower than another model, but you sense more of a delay with the "lower latency" audio interface, it very well might not be lower.

WHAT ABOUT "DIRECT MONITORING"?
You may have heard about an audio interface feature called "direct monitoring," which supposedly reduces latency to nothing, so what you hear as you monitor is essentially in real time. However, it does this by monitoring the signal going into the computer and letting you listen to that, essentially bypassing the computer (Fig. 3).


Fig. 3: TASCAM's UH-7000 interface has a mixer applet with a monitor mix slider (upper right). This lets you choose whether to listen to the input, the computer output, or a combination of the two.

While that works well for many instruments, suppose you're playing guitar through amp simulation plug-in running on your computer. If you don't listen to what's coming out of your computer, you won't hear what the amp simulator is doing. As a result, if you use an audio interface with the option to enable direct monitoring, you'll need to decide when it's appropriate to use it.

THE VIRTUES OF USING HEADPHONES

One tip about minimizing latency is that if you're listening to monitor speakers and your ears are about 3 feet (1 meter) away, you've just added another 3 ms of latency. Monitoring through headphones will remove that latency, leaving only the latency caused by using the audio interface and computer.

MAC VS. WINDOWS

Note that there is a significant difference between current Mac and Windows machines. Core Audio is a complete audio sub-system that already includes drivers most audio interfaces can access. Therefore, as mentioned earlier, it is usually not necessary to load drivers when hooking an audio interface up to the Mac. With Windows, audio interfaces generally include custom drivers you need to install, that are often on a CD-ROM included with the interface. However, it's always a good idea to check the manufacturer's web site for updates—even if you bought a product the day it hit the stores. With driver software playing such a crucial part in performance, you want the most recent version.

With Windows, it's also very important to follow any driver installation instructions exactly. For example, some audio interfaces require that you install the driver software first, then connect the interface to your system. Others require that you hook up the hardware first, then install the software. Pay attention to the instructions!

THE FUTURE AND THE PRESENT

Over the last 10 years or so, latency has become less and less of a problem. Today's systems can obtain very low latency figures, and this will continue to improve.

But if you experience significant latencies with a modern computer, then there's something wrong. Check audio options, drivers, and settings for your host program until you find out what's causing the problem.

Elantric

#1
http://www.soundonsound.com/sos/jan05/articles/pcmusician.htm

Optimising The Latency Of Your PC Audio Interface
PC Musician
Published in SOS January 2005

Technique : PC Musician
If you're tempted to go and make a cup of tea in the gap between pressing a note on your keyboard and hearing it play on your soft synth, you need help, and quickly...
Martin Walker



Choosing ASIO drivers, where possible, should help you achieve the lowest latency, using the Control Panel window provided by your particular audio interface. Here you can see the Control Panels for the Echo (left) and Emu (right) ranges, as launched from the Cubase SX Device Setup window.
The SOS Forums are still awash with queries from new PC musicians asking why they get a delay between pressing a key on their MIDI keyboard and hearing the output of a soft synth on their computer. Sometimes this delay may be as much as a second, making 'real time' performances almost impossible. Newcomers to computer music soon cotton on to the fact that this is because of 'latency' and 'buffer sizes', but are often left wondering just what to adjust and what the 'best' setting is.

Setting the correct buffer size is crucial to achieving optimum performance from your audio interface: if it's too small you'll suffer audio clicks and pops, while if it's too large you'll encounter audible delays when performing in real time. The ideal setting can depend on quite a few different factors, including your particular PC and how you work with audio, while the parameters you're able to change, and how best to do it, can also vary considerably depending on which MIDI + Audio application you use.


Buffers: The Basics
Let's start by briefly recapping on why software buffers are needed. Playing back digitised audio requires a continuous stream of data to be fed from your hard drive or RAM to the soundcard's D-A (digital to analogue) converter before you can listen to it on speakers or headphones, and recording an audio performance also requires a continuous stream of data, this time being converted by the soundcard's A-D (analogue to digital) converter from analogue waveform to digital data and then stored either in RAM or on your hard drive.

No computer operating system can do everything at once, so a multitasking operating system such as Windows or Mac OS works by running lots of separate programs or tasks in turns, each one consuming a share of the available CPU (processor) and I/O (Input/Output) cycles. To maintain a continuous audio stream, small amounts of system RAM (buffers) are used to temporarily store a chunk of audio at a time.


Some plug-ins add latency to the audio path, as revealed by this Plug-In Information window in Cubase SX. The window shows which plug-ins exhibit additional latency when used, and whether or not to automatically compensate for it.
For playback, the soundcard continues accessing the data within these buffers while Windows goes off to perform its other tasks, and hopefully Windows will get back soon enough to drop the next chunk of audio data into the buffers before the existing data has been used up. Similarly, during audio recording the incoming data slowly fills up a second set of buffers, and Windows comes back every so often to grab a chunk of this and save it to your hard drive.

If the buffers are too small and the data runs out before Windows can get back to top them up (playback) or empty them (recording) you'll get a gap in the audio stream that sounds like a click or pop in the waveform and is often referred to as a 'glitch'. If the buffers are far too small, these glitches occur more often, firstly giving rise to occasional crackles and eventually to almost continuous interruptions that sound like distortion as the audio starts to break up regularly.

Making the buffers a lot bigger immediately solves the vast majority of problems with clicks and pops, but has an unfortunate side effect: any change that you make to the audio from your audio software doesn't take effect until the next buffer is accessed. This is latency, and is most obvious in two situations: when playing a soft synth or soft sampler in 'real time', or when recording a performance. In the first case you may be pressing notes on your MIDI keyboard in real time, but the generated waveforms won't be heard until the next buffer is passed to the soundcard. You may not even be aware of a slight time lag at all (see 'Acceptable Latency Values' box), but as it gets longer it will eventually become noticeable, then annoying, and finally unmanageable.

During recording, the situation is even worse, since you normally won't be able to hear the incoming signal until it has passed through the input buffers and reached the software application, then passed through a second set of output buffers on its way to the soundcard's D-A converter, and then to your speakers or headphones. 'Monitoring' latency is double that of playback latency.

Plug-in effects can also add their own processing latency, particularly compressors, limiters and de-essers that look ahead in the waveform to spot peaks, plus pitch-shifters and convolution-based reverbs that employ extensive computation. Any tracks in your song using these effects would be delayed compared with the rest, so to bring them all back into perfect sync most MIDI + Audio applications now offer automatic 'delay compensation' throughout the entire audio path. Unfortunately, this can also add to the record-monitoring latency, although some applications (including Cubase SX) now provide a 'Constrain Delay Compensation' function, which tries to minimise the effects of delay compensation during the recording process, by temporarily disabling those plug-ins whose inherent latency is above a certain threshold (you set this in the Preferences dialogue). Activating this function during an audio recording or soft-synth performance may allow less 'real-time' latency. You can then deactivate it to hear every plug-in again.


Zero-latency Monitoring
As you can see, latency can be a complex and potentially confusing issue. Fortunately, many audio interfaces provide so-called 'zero-latency monitoring' for recording purposes. This bypasses the software buffers altogether, routing the interface input directly to one of its outputs. However, as I explained in my article 'The Truth About Latency' (see 'Further Reading' box), the total latency value isn't just that of the buffers. The audio signals also have to pass through the A-D and D-A converters on their way into and out of the computer, which adds a small further delay.

Converters usually add a delay of about 1ms each, but there may be other hidden delays as the signals pass through the soundcard, caused by the addition of features such as sample-rate conversion for rates of 32kHz or lower, which are sometimes not directly supported by modern converters. So 'zero'-latency monitoring actually means about 2ms latency, which is still almost undetectable in most situations. It's incredibly useful during recording, because the performers can listen to their live performance without any audible delay, which makes it far easier to monitor via headphones, for instance. However, it does have one unfortunate side-effect: you can't hear the input signal with plug-in effects, which prevents you from giving vocalists some reverb 'in the cans' to help with pitching, or guitarists some distortion, for example. One way around this is to buy an interface with on-board DSP effects and use them instead. Another is to use an external hardware unit to add effects. In both cases it's generally possible to connect them up such that you can hear the performance with effects, but still record it 'dry', for maximum flexibility during later mixdowns.

Unfortunately, you can't use zero-latency monitoring with soft synths or soft samplers, whose waveforms must always be passed though a set of software buffers before being heard. So we need to keep the buffer size as small as possible, to minimise the time between hitting a note and hearing the result.


Value Judgements
Some audio-interface manufacturers make life easy for you by directly providing the playback latency value in milliseconds at the current sample rate in their Control Panel utilities — although I've come across a few that provide incorrect values! Many applications also provide a readout of this latency time. If your audio application or soundcard provides a readout of buffer size in samples instead, it's easy to convert this to a time delay by dividing the figure provided by the number of samples per second. For instance, in the case of a typical ASIO buffer size of 256 samples in a 44.1kHz project, latency is 256/44100, or 5.8ms, normally rounded to 6ms. Similarly, a 256-sample buffer in a 96kHz project would provide 256/96000, or 2.6ms latency.



Your particular MIDI + Audio application (this screenshot shows Cubase SX 3) may support various audio-interface driver formats. The preferred options, if you have a choice, are ASIO, WDM, DirectX and MME, in that order.
Most of you will have spotted that running songs at a higher sample rate means lower latency, and some musicians assume that this is a major reason to make the switch. Unfortunately, doubling sample rate also doubles CPU overheads, since twice as much data has to be processed by plug-ins and soft synths in the same time period. You'll thus only be able to run half as many effects and notes as before, so do take this into account.

I've also mentioned in the past (notably in SOS June 2003) that the setting for audio interface buffers doesn't only affect latency, but also CPU overhead. However, many musicians forget this as they struggle to achieve the lowest possible latency for their system. The problem is that while the audio interface drivers take a negligible CPU overhead of their own to get started each time before the actual buffer filling and emptying takes place, and then to terminate afterwards, this small constant overhead can become increasingly significant at lower latency values. If, for example, your buffers are running with a sample rate of 44.1kHz and have a 12ms latency, they only need to be filled and emptied about 86 times per second. But if you attempt to reduce buffer size to 64 samples at 44.1kHz, to achieve a latency of 1.5ms, you have to fill these buffers 689 times a second, and each time you do the drivers consume their little extra overheads.

However efficient the driver programming, this will produce a noticeable hike in your CPU load, although some interfaces have more efficient drivers than others. Over the years I've noticed that nearly all interfaces give very similar values for CPU overhead, as measured inside applications such as Sonar and Cubase, when their latency is 12ms or higher. They can, however, vary considerably below this value, and USB and FireWire interfaces can sometimes impose a significantly higher overhead at low latencies than do PCI or PCMCIA interfaces.


Acceptable Latency Values
Here are some thoughts on acceptable values for different recording purposes:
Vocals: This is the most difficult example, because anyone listening to their vocals in 'real time' will have headphones on, and therefore have the sounds 'inside their head'. A latency of even 3ms can be disconcerting in these conditions.
Drums & Percussion: I suspect most drummers will prefer to work with latencies of 6ms or under, which should provide an 'immediate' response.
Guitars: Electric guitarists generally play a few feet from their stacks, and since the speed of sound in air is roughly a thousand feet per second, each millisecond of delay is equivalent to listening to the sound from a point one foot further away. So if you can play an electric guitar 12 feet from your amp, you can easily cope with a 12ms latency.
Keyboards: Even on acoustic pianos there's a delay between your hitting a key and the corresponding hammer hitting the string, so a smallish latency of 6ms ought to be perfectly acceptable to even the fussiest pianists. Famously, Donald Fagen and Walter Becker of Steely Dan claimed to be able to spot 5ms discrepancies in their performances, but the vast majority of musicians are unlikely to worry about 10ms, and many should find a latency of 23ms or more perfectly acceptable with most sounds, especially pads with longer attacks.

Driver Options
Your application may support more than one driver format, in which case you've first got to decide on the best one. You'll have the easiest time if you can choose ASIO drivers. These generally offer the lowest latencies and CPU overheads, and are also supported by a wide range of host applications, including Steinberg's Cubasis, Cubase, Nuendo and Wavelab, Cakewalk's Project 5 and Sonar (from version 2.2 onwards), and Emagic's Logic Audio.



Sonar's WDM driver with Kernel Streaming support is capable of really low latencies once you've tweaked its Buffer Size slider.
The host application generally provides a button labelled 'Control Panel' that launches a simple utility unique to your audio interface, with a small selection of preset ASIO buffer sizes from which to choose. Playback generally stops as soon as the Panel appears, so that you can change the size, although some interfaces won't adopt your new value until you close and then re-launch the host app. However, there is sometimes a way around this. Cubase, for example, has a tick box labelled 'Release ASIO Driver in Background' that will give the Control Panel full control of the interface while its window is open, and then return control to Cubase as soon as you close it, with the new buffer size in force.

( NOTE: Stale Information Alert! Info below has changed since 1999, as Sony Sound Forge now is cross-platform ( Win/OSX) and works today works with  Core Audio(OSX)  and ASIO (Win) drivers 
Anyone running Tascam's Gigastudio will require GSIF drivers, which mostly provide a fixed but low latency of between 6ms and 9ms and thus will work very well from day one without any tweaking. However, some modern interfaces provide a range of GSIF buffer sizes under Windows XP, generally chosen using a similar utility to the ASIO Control Panel.

WDM drivers are also capable of excellent performance with some applications (particularly Sonar), but generally take more setting up to achieve the lowest latency values, since you can often choose both the number of buffers and their sizes. Where and how to adjust these depends on the individual application (see next section). If your audio interface only has WDM drivers that provide mediocre performance but your application is ASIO-compatible, try downloading Michael Tippach's freeware ASIO4ALL driver (http://michael.tippach.bei.t-online.de/asio4all). This is a universal ASIO overlay that sits on top of any device's existing WDM driver to provide it with full ASIO support, and often far lower latencies.

DirectSound drivers can often provide good playback performance but rarely offer equivalent recording performance, so in the absence of ASIO or WDM drivers this often makes them a good choice for playing soft synths. Finally, some applications, such as Sound Forge, only support MME drivers. Even with Sound Forge's Buffer size (found in the Wave page of Options/Preferences) set to its minimum 96kb size you'll still hear a noticeable delay in some circumstances.


Elantric

#2

Latency Hints & Tips
If you're streaming samples from a hard drive for an application such as Gigastudio, HALion or Kontakt, using a drive with a low access time will help you achieve the minimum latency.
During playback and mixdown, latency largely determines the time it takes after you press the play button to actually begin hearing your song. Few people will notice a gap even as large as 100ms in this situation.
If you're running a pre-mastering application such as Wavelab or Sound Forge, you don't often need to work with a low latency. Few people notice the slight time lag between altering a plug-in parameter and hearing the audio result when mastering, even when this lag is 100ms or more. The only time I find a high mastering latency annoying is when I'm bypassing a plug-in (A/B switching) to hear its effect on the sound. You ideally need the change-over to happen as soon as you click the Bypass button, but most people still won't notice a latency of 23ms in this situation.
When using a hardware MIDI controller for automation you may not need low latency, but it's generally preferable when inputting 'real time' synth changes such as fast filter sweeps, to ensure the most responsive interface between real and virtual knobs.
During monitoring of vocals you may be able to use 'zero-latency' monitoring for the main signal, but still add plug-in reverb using a latency of 23ms or more without causing any delay problems, as long as you use the effect totally 'wet'.

Some Application Examples
Each audio application tucks away driver and buffer-size choices in a slightly different place, although menus labelled Audio, Preferences or Setup are a good place to start looking.

Sonar: Sonar runs a 'Wave Profiler (WDM Kernel Streaming)' utility when you first start the application, to determine the optimum size for its buffers at all available sample rates, but you can run this again at any time by clicking the Wave Profiler button on the General page of Audio Options. This sets up the MME and WDM drivers for a safe but conservative latency, whose current value can be seen below the Buffer Size slider in the Mixing Latency section on this same page (see screen above). You can nearly always move this slider further to the left to reduce latency (typically 99ms), as well as lowering the setting for 'Buffers in Playback Queue' if it's not already set to its lowest value of two. Move the slider to a new value, close the Audio Options window, then restart playback of the current song and listen for clicks and pops, as well as checking the new CPU-meter reading. In my experience, this meter reading can double between latencies of about 12ms and 3ms.

If you prefer to use Sonar with ASIO drivers, you can change the Drive Mode in the Playback and Recording section of the Advanced Audio Options page from WDM/KS to ASIO. Then exit Sonar and restart it for the change to take effect. The Mixing Latency of Audio Options will now be greyed out, and you can click on the new ASIO Panel button to launch the familiar control panel for your particular audio interface. When you close this, the new value takes effect immediately. However, the Effective Latency value shown in Audio Options only gets updated the next time you launch this window. According to my tests with Sonar's CPU meter, ASIO drivers generally give slightly lower CPU overhead than their WDM counterparts at latencies lower than about 12ms.

Cubase SX 3: Click on Device Setup in the Device menu and then choose 'VST Audiobay' (or 'VST Multitrack' in SX 1 and 2) in the left-hand column. The type of ASIO driver can be chosen in the drop-down box at top right. By far the best choice is a true ASIO driver, such as either the ASIO Echo WDM or EMU ASIO entries shown in the screen shot on page 118. You can then choose a suitable buffer size by clicking on your new driver's name in the left-hand column, and then on the Control Panel button.

The 'ASIO Multimedia' driver is generally the worst choice, since this will require you to set up the number of buffers and their size by hand, using the Advanced Options launched from the Control Panel button, and will always result in much higher latency. The best I've ever managed with my Echo Mia card is three buffers of 1024 samples, resulting in a playback latency of 93ms. Rather better is 'ASIO DirectX Full Duplex Driver', which my Echo Mia card can run with a single 768-sample buffer, resulting in a reasonable latency of 17ms.

Wavelab: Click on Preferences in the Options menu, and then on the Audio Card tab. Here you can choose different drivers for Playback and Recording, which can be useful if you have several interfaces installed in your PC (this only applies to the MME-WDM options — choosing any ASIO driver for playback greys out the recording selections). Unusually, choosing an ASIO option still allows you to select the number of buffers, so it's important to give this the lowest setting (three) if you want really low latency.

The MME-WDM options default to six buffers with a size of 16384 bytes each, giving a huge latency of 557ms at 44.1kHz, but you can nearly always reduce this to four buffers of 16384 bytes (371ms) with no problems. If you go lower, you may find that playback is glitch-free but that juddering occurs when you display the drop-down lists of plug-ins in the Master Section. My Echo Mia card can manage five 4096-byte buffers producing 116ms of latency, which is quite low enough for most mastering purposes. However, choosing ASIO drivers is generally a much better option if they are available.

Native Instruments soft synths: Most of these can run either as VST or DX Instruments inside a compatible host application, or as stand-alone synths using ASIO, DirectSound or MME drivers. If you choose either of the latter two options there's a single Play Ahead slider to tweak for the lowest latency. Many interfaces manage the lowest MME setting of 10ms under Windows 98SE, but under Windows XP 40ms is more typical. DirectSound drivers generally manage 25ms or less, which can be perfectly acceptable, under all versions of Windows.

Further Reading
Choosing A PC Audio Interface: SOS November 2004
www.soundonsound.com/sos/nov04/articles/pcmusician.htm
DSP-assisted Audio Effects & Latency: SOS April 2004
www.soundonsound.com/sos/apr04/articles/pcmusician.htm
Using Hardware Effects With Your PC Software Studio: SOS March 2004
www.soundonsound.com/sos/mar04/articles/pcmusician.htm
PC Musician Jargon Buster: SOS February 2004
www.soundonsound.com/sos/feb04/articles/pcmusician.htm
The Truth About Latency: SOS September 2002
www.soundonsound.com/sos/Sep02/articles/pcmusician0902.asp
The Truth About Latency Part 2 : SOS October 2002
www.soundonsound.com/sos/Oct02/articles/pcmusician1002.asp
Hear No Evil: SOS August 1999
www.soundonsound.com/sos/aug99/articles/zerolatency.htm
Mind The Gap: SOS April 1999
www.soundonsound.com/sos/apr99/articles/letency.htm

The Best Latency
So what's the best buffer size for your system? This isn't straightforward to answer. If you mainly play soft synths and soft samplers, or you're recording electric guitar, a 6ms ASIO or WDM/KS latency (256 samples at 44.1kHz) is probably low enough to be unnoticeable, and won't increase your CPU overhead too much. However, if you're one of the many musicians who don't notice a 12ms latency, adopting a 512-sample buffer size at 44.1kHz will probably allow you more simultaneous notes and plug-ins.

The best way to find out is to set a latency value of about 23ms (a buffer size of 1024 samples at 44.1kHz), and then choose a soft-synth sound with as fast an attack as possible (slow-attack pads can easily be played with latencies of over a second!) See if you can detect any hesitation before each note starts, while you're playing in real time from a MIDI keyboard, and don't be embarassed if you can't! If you can detect a hesitation and you find this latency noticeable or even annoying, reduce the buffer to the next size down and try again, until you decide on a latency that works for you. This way you won't be wasting your processor's time by making it constantly fill unnecessarily tiny buffers.

Whatever the latency value you choose, you may have to adopt a lower one when monitoring vocals during recording, if you want to add plug-in effects 'live'. Set the buffers inside your particular MIDI + Audio application to a high latency of about 23ms and then start playback of an existing song. Watch the application's CPU meter and note its approximate reading. Now choose the next buffer size down and try again. If playback is still glitch-free, keep going, a setting at a time, until tell-tale clicks and pops start to appear. If you're lucky this won't happen until a 3ms or even lower latency, and may not even occur at the lowest available setting provided by your audio interface. But as soon as you hear even a single click, move back to the next buffer size up and try again, until you're sure that the current buffer setting is the lowest that is totally reliable. At the same time, note any increases in the CPU meter reading compared with its 23ms setting — if it's risen considerably, you'll probably find it preferable to only use this low latency during recording when you really need it for monitoring purposes, returning to your previously chosen playback setting at all other times. It's rare to run into any problems other than glitching when you're trying low ASIO or WDM buffer values. However, with MME and DirectSound drivers you may experience intense waveform breakup that can sometimes even crash your PC, so be very cautious when setting these driver buffer sizes below about 40ms. Change the value in small steps, and stop as soon as you start to experience glitching.

Many musicians adopt a two-stage approach — a low latency value during the audio-recording phase and a more modest one during soft-synth recording, playback and mixdown, when they can add more plug-ins. And while these procedures may sound complex, they should only take you an hour, at most, to complete, and you only need to perform them once with a particular combination of audio interface, driver version and PC. Once you've found the most suitable latency value for playback and the lowest possible latency supported by your particular PC, you'll know you're making the best use of your processor in all situations.

Elantric

#3
http://wiki.audacityteam.org/wiki/Multichannel_Recording
Windows Sound Interfaces

MME

The standard Windows MME (Multi Media Extensions) sound interface has been around since Windows 3.1. It supports up to two channels of recording, sample depths up to 16 bits, and sample rates up to 44100Hz. On playback, multiple applications can use the sound device at the same time, with all the audio being mixed and sample rate converted to 44100Hz in Windows before being sent to the soundcard. Nice and simple for going ping and utterly hopeless for multi-channel music production.

DirectSound
It's also not very much use for writing games with, which is why after the release of Windows 95, it became necessary to offer the games manufacturers something better to persuade them off DOS. So DirectSound was born. This provided more flexible playback of audio, and later added multi-channel and surround sound playback for immersive game audio. Recording support was added later. DirectSound offers somewhat lower latencies than MME, and the possibility of multi-channel recording on some devices.

ASIO
So in the meantime, serious audio recording and playback was left out in the cold. Proprietary solutions stepped into the gap, and Steinberg created the ASIO interface for bypassing the operating system entirely, and connecting audio applications direct to the soundcard. This gives very low latencies (because all the mixing and conversion involved in the MME interface is avoided), but means that only one application can use a soundcard at a time (no sharing between multiple applications, no system sounds).
Audacity supports ASIO but that support is not distributed in releases for licensing reasons. Audacity can be compiled with ASIO support as long as that build is not distributed to others.

GSIF
also arrived about this time, but is proprietary and completely playback-only, so doesn't affect us.

WDM-KS
Then Microsoft wanted to provide a way to do what ASIO did but that they controlled, and integrated better with existing MME drivers. So Windows Driver Model Kernel Streaming (WDM-KS) and Enhanced Windows Driver Model (EWDM) drivers were invented. These provided a unified way of writing drivers for Windows 2000 onwards, multi-channel support and more direct access into the audio hardware for applications that needed it (and thus significantly reduced latency). As with ASIO, only one application can use the soundcard at a time, but multiple soundcards can be aggregated.

Cakewalk's SONAR was the first major application to use this, and it still lags behind ASIO in terms of market penetration on the application side. Drivers are more widespread, because providing any kind of WDM driver automatically provides DirectSound and MME support through Windows. But WDM drivers not specifically designated as WDM-KS or EWDM generally won't provide multi-channel recording support - as this isn't needed for DirectSound or MME, many driver writers omit it. Also drivers that nominally support WDM-KS may be badly written, causing a computer crash.

WASAPI
In 2005 the WASAPI application programming interface (API) was introduced starting with Windows Vista. WASAPI isolates audio more from the kernel so providing greater stability, allows a few further multi-channel devices to work without ASIO and provides lower latency than MME and Windows DirectSound.
On the other hand, direct hardware access under WASAPI is limited to a WaveRT driver which only a few built-in devices support (also, Audacity and many other audio programs do not support it). Latencies under WASAPI are higher than under WDM-KS, and latencies under MME and DirectSound are higher than they were on Windows XP because MME and DirectSound are both emulated over WASAPI. To compensate for this, Windows Store applications on Windows 8 can support offloading of audio processing to hardware which was dropped with Vista. This is a necessary step for modern battery-dependent devices where software audio processing on the CPU would rapidly deplete battery life.
WASAPI has two significant benefits for Audacity.
24-bit recording is supported (Windows DirectSound supports 24-bit recording, but the PortAudio API Audacity uses does not support 24-bit input under DirectSound).
From version 2.0.4 onwards, Audacity supports recording computer playback (even where sound devices don't support this) using Windows WASAPI loopback recording. For the audio to be captured, the audio device playing the audio must be in shared mode ("Exclusive Mode" unchecked in the Windows "Sound" Control Panel).
External article about Windows API's

For more on how Windows sound drivers work, and the different API's, see this article by Claus Riethmüller. Note: after that page was written, DirectSound added recording support, as mentioned above.



Elantric

#6
http://www.soundonsound.com/forum/showflat.php?Cat=&Number=918351&page=&view=&sb=5&o=&fpart=11&vc=1

in 2016, PCIe Audio interfaces have lower latency than Firewire,Thunderbolt, USB
(click image to expand)



acousticglue

The one thing I just found out after a long time having issues with 2 plugins (BiasFX and Amplitube3--4) is not only to turn off power saving but in BIOS I had missed power for SATA drives. This has been causing issues with pixel driven VSTs and I knew disk activity was part of it. Now that is off I run these programs at 32 buffer on Layla24 glitch free.

alexmcginness

If its the same guy doing these tests his results are inconsistent. The RTL for the MOTU card with the same driver varies considerably. the 64 buffer setting on your chart is posted as 5.125 and in a chart half way down this page its posted at 3.923.

scroll down to the post on July 14th 2011. https://www.gearslutz.com/board/music-computers/618474-audio-interface-low-latency-performance-data-base.html
VG-88V2, GR-50, GR-55, 4 X VG-99s,2 X FC-300,  2 X GP-10 AXON AX 100 MKII, FISHMAN TRIPLE PLAY,MIDX-10, MIDX-20, AVID 11 RACK, BEHRINGER FCB 1010, LIVID GUITAR WING, ROLAND US-20, 3 X GUYATONE TO-2. MARSHALL BLUESBREAKER, SERBIAN ELIMINATOR AMP. GR-33.

jassy

Quote from: acousticglue on July 13, 2016, 02:11:57 AM
The one thing I just found out after a long time having issues with 2 plugins (BiasFX and Amplitube3--4) is not only to turn off power saving but in BIOS I had missed power for SATA drives. This has been causing issues with pixel driven VSTs and I knew disk activity was part of it. Now that is off I run these programs at 32 buffer on Layla24 glitch free.
Sorry for my ignorance, what are pixel driven VSTs?
What BIOS setting are you suggesting exactly with "power for SATA drives"?

acousticglue

When running a vst such as biasfx it pulls the images off hard disk and you can watch disk activity in task manager resources. The bios settings is under power settings and enabled for sata generally

Elantric

http://masters-of-music.com/audient-id4-vs-focusrite-scarlett-latency-comparisons-windows/
Audient iD4 vs Focusrite Scarlett Latency Comparisons (Windows)
JULY 23, 2016

Audient iD4 vs Scarlett 2i2

Below is a list comparing the overall latency numbers between the Audient iD4 and the 1st and 2nd generation Focusrite Scarlett interfaces on a Windows 7 computer.

Over the past couple of months Focusrite and Audient have both released new USB audio interfaces.



Audient released the iD4 and Focusrite released 2nd generation Scarlett interfaces, which includes six different models with varying levels of inputs and outputs.

Last month I posted a review of the 2nd gen Scarlett 2i2, along with a comparison review between the 1st gen 2i4.

The 2nd gen 2i2 has incredibly low latency, and the unit itself it quite nice, but the Windows drivers have a few bugs that still need to be worked out, so that's why I got the Audient iD4 to try.

I'll post a comparison review and video showing them both next week, but for this article let's just focus on the latency differences between them.

Here's a list of the overall latency numbers according to Ableton Live 9 using a Windows 7 64-bit computer.

Audient iD4 – Overall Latency

Audient does things differently than Focusrite when it comes to latency and buffer size settings. They have 6 separate settings for latency modes, and each has a different minimum buffer size setting:

Windows Latency Modes
Minimum
Low
Standard
Relaxed
Safe
Extra Safe

These are the lowest latency numbers using the Minimum setting:

4.9 ms at 44kHz/64 samples
4.67 ms at 48kHz/64 samples
4.9 ms at 88kHz/128 samples
4.67 ms at 96kHz/128 samples

However, the Audient iD4 won't work when using the Minimum latency setting on my computer; it crackles constantly even at 0% CPU load, so those numbers are irrelevant to me.

The Low latency setting works well on my PC so these are the latency numbers for it at the lowest buffer size settings:

9.8 ms at 44kHz/128 samples
9.33 ms at 48kHz/128 samples
9.8 ms at 88kHz/256 samples
9.33 ms at 96kHz/256 samples

Note: The settings above work fine under a heavy load with Pro Tools 12 but for some reason I get some crackling with Ableton Live 9 when using these setting so I'm trying to figure that out. It runs smoothly in Ableton at 48kHz/256 but the latency is 14.7 ms, and that's higher than what I can get with the 1st gen 2i4...

Focusrite Scarlett 2i4 (1st Gen) – Overall Latency

The great thing about the 1st gen 2i4 is the drivers work so well that I can run it at these highest settings below all the time even up to 90% CPU without the slightest issue.

13.5 ms at 44kHz/64 samples
12.4 ms at 48kHz/64 samples
10.4 ms at 88kHz/128 samples
9.5 ms at 96kHz/128 samples

Focusrite Scarlett 2i2 (2nd Gen) – Overall Latency

The 2nd gen Scarlett interfaces support higher sample rates than the 1st gen models and the Audient iD4.

The highest settings on the 2nd gen 2i2:

5.31 ms at 44kHz/32 samples
5.17 ms at 48kHz/32 samples
3.85 ms at 88kHz/32 samples
3.63 ms at 96kHz/32 samples
3.08 ms at 176kHz/32 samples
3.06 ms at 192kHz/32 samples

Unlike the Audient iD4, the 2nd gen 2i2 runs fine without crackling at the highest settings so those numbers are doable with my computer. However, the CPU hit at those settings is considerable, so I usually track guitars and my Alesis e-drums at 64 samples with 7.8 ms of latency and that works very well.

Elantric

#12
https://web.archive.org/web/20170506174453/https://www.presonus.com/learn/technical-articles/The-Truth-About-Digital-Audio-Latency

The Truth About Digital Audio Latency
By Wesley Elianna Smith

In the audio world, "latency" is another word for "delay." It's the time it takes for the sound from the front-of-house speakers at an outdoor festival to reach you on your picnic blanket. Or the time it takes for your finger to strike a piano key, for the key to move the hammer, for the hammer to strike the string, and for the sound to reach your ear.

Your brain is wired so that it doesn't notice if sounds are delayed 3 to 10 milliseconds (ms). Studies have shown that sound reflections in an acoustic space must be delayed by 20 to 30 ms before your brain will perceive them as separate. However, by around 12 to 15 ms (depending on the listener), you will start to "feel" the effects of a delayed signal. It is this amount of delay that we must battle constantly when recording and monitoring digitally.

When Good Latency Goes Bad
Roundtrip latency in digital-audio applications is the amount of time it takes for a signal (such as a singing voice or a face-melting guitar solo) to get from an analog input on an audio interface, through the analog-to-digital converters, into a DAW, back to the interface, and through the digital-to-analog converters to the analog outputs. Any significant amount of latency can negatively impact the performer's ability to play along to a click track or beat — making it sound like they're performing in an echoing tunnel (unless they have a way to monitor themselves outside of the DAW application, such as a digital mixer or one of our AudioBox™ VSL-series interfaces).

What's Producing the Delay: a Rogue's Gallery
In practical terms, the amount of roundtrip latency you experience is determined by your audio interface's A/D and D/A converters, its internal device buffer, its driver buffer, and the buffer setting you have selected in your digital audio workstation software (Mac®) or Control Panel (Windows®).

Converters. Analog-to-digital converters in your interface transform an analog signal from a microphone or instrument into digital bits and bytes. This is a ferociously complex process and takes a little more than half a millisecond on average. On the other end of a long chain we're about to describe are the digital-to-analog converters that change the digital stream back into electrical impulses you can hear through a monitor speaker or headphones. Add another half-millisecond or so.



Buffers. A buffer is a region of memory storage used to temporarily hold data while it is being moved from one place to another. There are four of these in the digital signal chain.

USB Bus Clock Front Buffer
ASIO (Driver) Input Buffer
ASIO (Driver) Output Buffer
USB Clock Back Buffer

Each buffer contributes to the total delay present between the time you play that hot guitar solo and the time you hear it back in your headphones.

Fast Drivers and Slow Drivers
The biggest variable that contributes to how long this process will take is driver performance.


Studio One buffer setting.
In computing, a driver is a computer program allowing higher-level computer programs to interact with a hardware device. For example, a printer requires a driver to interact with your computer. A driver typically communicates with the device through the computer bus or communications subsystem to which the hardware connects. Drivers are hardware-dependent and operating-system-specific.

One of the primary goals for engineers who design audio-interface drivers is to provide the best latency performance without sacrificing system stability.

Imagine that you're playing an old, run-down piano and that there is a catch in the hammer action—so great a catch, in fact, that when you strike a key, it takes three times longer than normal for the hammer to strike the string. While you may still be able to play your favorite Chopin etude or Professor Longhair solo, the "feel" will be wrong because you'll have to compensate for the delayed hammer-strikes.

You will have a similar problem if the buffer-size setting is too large when you overdub a part while monitoring through your DAW.

Take a Couple Buffers and Call Us in the Morning
A buffer is designed to buy time for the processor; with the slack the buffer provides, the processor can handle more tasks. When the buffer size is too large, it's delaying the data—adding latency—more than is necessary for good computer performance.

But if the buffer size is too small, the processor has to work faster to keep up, making it more vulnerable to overload, so your computer-recording environment becomes less stable.

Consider this scenario: You're playing your favorite virtual instrument, trying to add one more pad part to a nearly finished song. All 42 tracks are playing back, and all of them use plug-ins. And then it happens: Your audio starts to distort, or you start hearing pops and clicks, or, worse, your DAW crashes because your CPU is overloaded. The 64-sample buffer size you have set, in conjunction with the amount of processing that your song requires, overtaxes your computer.

Smaller buffer, less delay (but an unhappy CPU). Larger buffer, more stable CPU...but more delay.
Smaller buffer, less delay (but an unhappy CPU). Larger buffer, more stable CPU...but more delay.

If you increase the buffer size, you can get the software crashing to probably go away. But it's not that simple.

The more that you increase the buffer size — for example, up to 128 samples — the more you notice the latency when trying to play that last part. Singing or playing an instrument with the feel you want becomes extremely difficult because you have essentially the same problem as with that rickety piano's delayed hammer-strikes. What you play and what you hear back in your headphones or monitor speakers get further and further apart in time. Latency is in the way. And you're in that echo-y tunnel again.

Let's look at our piano example again, this time with a fully functioning baby grand and not that antique piano in desperate need of repair. For simplicity's sake, let's pretend that there is no mechanical delay between the time your finger strikes the key and the hammer strikes the string. Sound travels 340 meters/second. This means that if you're sitting one meter from the hammer, the sound will not reach your ears for a little more than 3 ms. So why does 3 ms not bother you a bit when you're playing your grand piano, but a buffer setting of 2.9 ms (128 samples at 44.1 kHz) in your DAW make it virtually impossible for you to monitor your guitar through your favorite guitar amp modeling plug-in?

Decoding Latency
As mentioned earlier, roundtrip latency is the amount of time it takes for a signal (such as a guitar solo) to get from the analog input on an audio interface, through the A/D converters, into a DAW, back to the interface, and through the D/A converters to the analog outputs. But you can only control one of part of this chain: the input latency—that is, the time it takes for an input signal such as your guitar solo to make it to your DAW.

This is where driver performance enters the picture. There are two layers to any isochronous driver (used for both FireWire and USB interfaces). The second layer provides the buffer to Core Audio and ASIO applications like PreSonus Studio OneTM and other DAWs. This is the layer over which you have control.

To make matters worse, you usually are not given this buffer-size setting as a time-based number (e.g., 2.9 ms); rather, you get a list of sample-based numbers from which to choose (say, 128 samples). This makes delay conversion more complicated. And most musicians would rather memorize the lyrics to every Rush song than remember that 512 samples equates to approximately 11 to 12 ms at 44.1 kHz! (To calculate milliseconds from samples, simply divide the amount of samples by the sample rate. For example, 512 samples/44.1 kHz = 11.7 ms.)

The buffer size that you set in your DAW (Mac) or in your device's Control Panel (Windows) determines both the input and the output buffer. If you set the buffer size to 128 samples, the input buffer and the output buffer will each be 128 samples. At best, then, the latency is twice the amount you set. However, the best case isn't always possible due to the way audio data is transferred by the driver.

For example, if you set your ASIO buffer size to 128 samples, the output latency could be as high as 256 samples. In that case, the two buffers combine to make the roundtrip latency 384 samples. This means that the 2.9 ms of latency you set for your 44.1 kHz recording has become 8.7 ms.

The analog-to-digital and digital-to-analog converters in an audio interface also have latency, as do their buffers. This latency can range from 0.2 to 1.5 ms, depending on the quality of the converters. An increase of 1 ms of latency isn't going to affect the quality of anyone's performance. However, it does add to the total roundtrip latency. For our 128-sample example setting, adding 0.5 ms for each converter brings the roundtrip latency to 9.7 ms. But 9.7 ms is still below the realm of human perception, and it shouldn't affect your performance.

So Where Does the Extra Delay Really Come From?
The culprit is that first mysterious audio-driver layer that no one ever discusses. This lowest layer has no relationship to audio samples or sample rate. In the case of USB, it is a timer called the USB Bus clock. (There is a similar clock for FireWire processes but we will only discuss the USB Bus clock here.)

The USB Bus clock is based on a one-millisecond timer. At an interval of this timer, an interrupt occurs, triggering the audio processing. The problem that most audio manufacturers face is that without providing control over the lower-layer buffer, users cannot tune the driver to the computer as tightly as they would like. The reason for not exposing this layer is simple: The user could set this buffer too low and crash the driver—a lot.

To get around this, most manufacturers fix this buffer at approximately 6 milliseconds. Depending on the audio driver, this could be 6 ms input latency and 6 ms output latency. But like the ASIO buffer discussed earlier, even if these buffer sizes are set to the same value, the resulting output latency can differ from the input latency.

For our example, let's keep things simple and say that latency is 6 ms in both directions. Our mystery is solved: With most audio interfaces, there is at least 12 ms of roundtrip latency built into the driver before the signal ever reaches your DAW, in addition to the 9.7 ms latency we calculated earlier.

Thus, you set 2.9 ms of delay in your DAW and end up with 21.7 ms of roundtrip latency. (All of the numbers in our examples are based on averages. However, some manufacturers are able to optimize driver performance to minimize these technical limitations.)

Overcoming the Problem
Many audio-interface manufacturers have solved the problem of monitoring latency through a DAW by providing zero-latency monitoring solutions onboard their interfaces.

One of the earliest solutions was the simple analog Mixer knob on the front panel of the PreSonus FirePod. This allowed users to blend the FirePod's analog (pre-converter) input signal with the stereo playback stream from the computer. This basic monitoring solution is still available on such interfaces as the PreSonus AudioBox USB, AudioBox 22VSL, and AudioBox 44VSL. Another solution, used in the PreSonus FireStudio™ family and many others, is to include an onboard DSP mixer that is managed using a software control panel.

While both of these solutions resolve the problem of latency while monitoring, they provide a flat user experience by giving control only over basic mix functions like volume, panning, solo, and mute.

Old-skool solution: Just grab some of the analog signal before it goes into the A/D converters and send it back to your headphones. It works but you can't hear any effects or reverb.
Old-skool solution: Just grab some of the analog signal before it goes into the A/D converters and send it back to your headphones. It works but you can't hear any effects or reverb.
Anyone who has ever recorded using one of our StudioLive™ mixers (anyone who has ever tracked with any mixer, for that matter) knows how important it is to be able to record a track while hearing effects (as well as compression and equalization). For example, if reverb on a vocal is going to be part of the final mix, it's almost impossible to record the vocal "dry" — phrasing and timing are totally different when you can't hear the duration and decay of the reverb.

The developers at PreSonus were intrigued by the idea that they could conceivably provide the user with some level of control over the USB Bus clock buffer and perhaps offer another way of monitoring outside the DAW (while adding effects and reverb). After much experimentation, they discovered that most modern computers can easily and stably perform at a much lower USB Bus clock buffer than previously thought. On average, a 2 to 4 ms USB Bus clock buffer offers both excellent performance and stability. On a powerful computer like a fully loaded Mac Pro, they've been able to lower this buffer to the lowest USB Bus clock setting possible: 1 ms.

Given these discoveries, not giving the user control over the USB Bus clock buffer and telling them that the only latency controls available are the ASIO and Core Audio buffer sizes seems at best duplicitous, and at worst a failure to provide customers with the best latency performance a modern computer can provide.

This is where AudioBox VSL-series interfaces enter the picture. This new series of interfaces takes advantage of these technological discoveries and provides users with the ultimate monitor-mixing experience, without including expensive onboard DSP and the proportional cost increase to customers.



Tracking with Reverb and Effects... without Being in a Tunnel
The Virtual StudioLive software that comes with our AudioBox 22VSL, 44VSL and 1818VSL interfaces looks like — and performs like — the Fat Channel on our StudioLive 16.0.2 mixer.

You get compression, limiting, 3-band semi-parametric EQ, noise gate, and high-pass filter. We've even included 50 channel presets from the 16.0.2 just to get you started. Plus you get an assortment of 32-bit reverbs and delay, each with customizable parameters.

Optimizing AudioBox VSL Software

AudioBox 44VSL Virtual StudioLive mixer and Fat Channel
AudioBox VSL monitoring software runs between the USB Bus clock buffer and the ASIO/ Core Audio buffer on your computer, so it is only subject to the latency from the USB Bus clock buffer.

Unlike many manufacturers, PreSonus did not fix this buffer at 6 ms; rather, AudioBox VSL offers a choice of three buffer sizes. To reduce the confusion of presenting the user with two types of buffer settings, these USB Bus clock buffer settings are labeled "Performance Mode."

This setting is available from the Setup tab in AudioBox VSL, and it directly affects the amount of latency you will hear in monitor mixes from AudioBox VSL software.

At the Fast setting, AudioBox VSL runs at a USB Bus clock buffer setting of 2 ms, while Normal sets the buffer to 4 ms, and Safe sets it to 8 ms. So when you set your AudioBox VSL to run at the Fast USB Bus clock buffer setting, roundtrip latency will be approximately 3.5 ms, including the time it
takes for the A/D – D/A converters to change analog audio to 1s and 0s and back to analog again.

To optimize these buffer settings for your particular computer:


CPU Performance Meter in Studio One 2 Artist DAW (comes free with AudioBox VSL interfaces).
Begin by creating a monitor mix in AudioBox VSL and setting the Performance mode to Fast.
Listen carefully for pops and clicks and other audio artifacts at a variety of sample rates.
Now load the AudioBox VSL with compressors, EQs, reverbs, and delays.
If you hear audio artifacts, raise the Performance mode to Normal. On most machines, Normal will provide the best performance with the most stability. If you have an older machine with a slower processor and a modest amount of RAM, you may need to raise this setting to Safe. Keep in mind, however, that even at 9 ms, AudioBox VSL is running at a lower latency than monitoring through most DAWs at the best ASIO/ Core Audio buffer setting—and the best buffer setting will not work on a slower computer anyway.
Once you have Performance mode tuned, the next latency component of the driver to tune is the ASIO buffer size (Windows) or Core Audio buffer size (Mac). This time, load a large session into your DAW and experiment with the buffer settings. Again, you are listening for pops and clicks and other audio artifacts.
If your DAW includes a CPU-performance meter (as Studio One does), you can use this to help you find the best buffer setting for your computer.

No matter how you set your ASIO/Core Audio buffer size, the monitoring latency in VSL is not affected. So you can set this buffer fairly high and lower it only when you are playing virtual instruments. Keep in mind that it's still important to determine the lowest threshold at which your DAW can still perform stably.

Elantric

#13
More reading
https://www.gearslutz.com/board/so-much-gear-so-little-time/879477-rme-fireface-ucx-vs-motu-ultralite-mkiii-latency.html



I have owned the Firewire-only version of the UltraLite and I'm a current owner of an RME UFX (the UCX's big brother), as well as several other interfaces. I recorded round-trip latency numbers for all interfaces, at 44.1kHz/256 samples. I used RTL Utility to test the interfaces, the same tool used in the DAWBench Low Latency Performance tests. (I use a 256 sample buffer in my day-to-day work because it provides a great amount of stability. I use Direct Monitoring when recording any vocals or hardware instruments, so I never feel the effects of latency. That doesn't work for everyone though, depending on their monitoring needs.)

Here are my results:


As you can see, the UFX interface has a 5-to-6ms advantage over the UltraLite, depending on whether I used USB or FireWire.

Note that the DAWBench scores take into account not just latency but bandwidth (which is why the PCI/PCIe interfaces crush everything else in the DAWBench rankings, even though the actual latency differences aren't that huge). You can scroll down past the "performance rating" graph to see the raw data for each interface at different buffer sizes.

EDIT: The UltraLite is a fine interface, by the way. RME does tend to deliver great low-latency performance, but for the premium you pay you're also getting lots of I/O connections, routing options, and very reliable drivers.

alexmcginness

Im using the MOTU PCIe 424 with 3 breakout boxes. I get good enough latency with my machine which is an HPZ800 dual hexcore with 48 gigs of ram. Those cards and the breakout boxes are going cheap now compared to what they use to be. Most folk would only ever need one 24I/O
VG-88V2, GR-50, GR-55, 4 X VG-99s,2 X FC-300,  2 X GP-10 AXON AX 100 MKII, FISHMAN TRIPLE PLAY,MIDX-10, MIDX-20, AVID 11 RACK, BEHRINGER FCB 1010, LIVID GUITAR WING, ROLAND US-20, 3 X GUYATONE TO-2. MARSHALL BLUESBREAKER, SERBIAN ELIMINATOR AMP. GR-33.

Elantric

PCI audio interfaces still rule!

Trouble is few folks still use desktop PCs

alexmcginness

Quote from: Elantric on August 19, 2016, 05:41:24 PM
Trouble is few folks still use desktop PCs

Their loss. I find the most effective recording set up is a Desktop system at home and one or more mobile setups.
VG-88V2, GR-50, GR-55, 4 X VG-99s,2 X FC-300,  2 X GP-10 AXON AX 100 MKII, FISHMAN TRIPLE PLAY,MIDX-10, MIDX-20, AVID 11 RACK, BEHRINGER FCB 1010, LIVID GUITAR WING, ROLAND US-20, 3 X GUYATONE TO-2. MARSHALL BLUESBREAKER, SERBIAN ELIMINATOR AMP. GR-33.

Elantric


admin

https://www.thegearpage.net/board/index.php?threads/windows-for-recording-ummmm-no.1805162/page-7

Jim Roseberry said: ↑


We've been building high-end Windows PC DAWs professionally for over 20 years.
Currently have many professional clients running Windows 10.
Recently sent a machine to Fred Coury (composer for TV/Film - drummer for Cinderella)

Windows 10 has *zero* to do with poor low-latency performance.
Your audio latency is determined by your audio interface and any latent plugins.
Regarding the audio interface driver, some use a small safety-buffer (RME/MOTU/Lynx)... others use a larger safety-buffer (Focusrite, Behringer, TC, etc).
If the audio interface uses a large safety-buffer (and does not allow the user to tweak it), you'll never achieve low round-trip latency (Mac or PC).
With most DAW applications having automatic plugin-delay-compensation (auto PDC), if you have a latent plugin/s inserted *anywhere* in the project, all other audio will be delayed by that amount (to maintain sample-accurate sync).
Avoid using latent plugins while tracking... or if your DAW software offers it, you can globally disable auto PDC while tracking.

The issue you run into with laptops (especially over-the-counter models), is that they're not built to function as a workstation.
The general-purpose user (Facebook, Email, Word, light Photoshop, etc) is far more concerned about long battery life than ultimate performance.
With a tight enclosure, performance compromises have to be made to keep thermal issues in check.
This is why there are "mobile" CPUs vs. "desktop" models.
Performance throttling is done to keep temps in check.
Performance throttling can raise DPC Latency (stands for Deferred Procedure Call - not to be confused with audio latency).
To effectively work at low audio latency settings, you need low/consistent DPC Latency.

More advanced laptops allow you to go in and tweak certain BIOS parameters that control performance throttling.
Most off-the-shelf machines don't expose these parameters (to keep less savvy users from fouling up their machine)... so you're thus SOL.
The highest performance custom laptops (Clevo shells) actually run a desktop i7 CPU (not the mobile version).
It's expensive, but it offers performance that can rival a fast tower. Smokes the top-tier MacBook Pro. Only downside is cost.

An off-the-shelf inexpensive laptop doesn't make a good DAW.
It was never designed for this purpose.
The general-purpose user would never notice a few ms hiccup in data flow (caused by high DPC Latency).
If you're trying to run heavy loads at a 64-sample ASIO buffer size, the machine has 1.5ms to get the next audio buffer processed/filled.
ie: In this scenario, a 2ms hiccup in data-flow means a glitch or (worse) a drop-out.

My personal studio DAW is running an i7-6850k (six cores - twelve processing threads) locked at 4GHz (OS is Win10x64 Pro).
My RME Fireface UFX *rarely* gets bumped above the smallest 48-sample ASIO buffer size.
Total round-trip latency is 4.3ms at 44.1k
This machine can sustain heavy loads (glitch-free) at that 48-sample ASIO buffer size.
The Mac Pro with the Intel Xeon E5-2697 is over $8k
https://www.bhphotovideo.com/bnh/controller/home?O=&sku=1025445&gclid=Cj0KEQjwhpnGBRDKpY-My9rdutABEiQAWNcslNteAeSIXRBlZt-s0Ia0D0X8kN2qH1BUPwoQuy1siJ4aAtjK8P8HAQ&is=REG&ap=y&c3api=1876,52934714882,&Q=&A=details

Refurbished from Apple is just under $8k
http://www.apple.com/shop/product/G0P88LL/A/Refurbished-Mac-Pro-27GHz-12-Core-Intel-Xeon-E5?afid=p238|s6wVuokT6-dc_mtid_1870765e38482_pcrid_52243312450_&cid=aos-us-kwgo-pla-mac--slid--product-G0P88LL/A

The processor itself is $2600:
https://www.newegg.com/Product/Prod...Core_Intel_Xeon_E5-_-9SIAAEE5739946-_-Product

When it comes to running audio DSP, you don't want to sacrifice significant clock-speed for more CPU cores.
We've done plenty of audio stress-tests over the past 20+ years.

Standard CPU benchmarks don't always translate to working with audio.
ie: The Ryzen 1800x handily outperforms the 6850k (both $500) running Cinebench.
However, if you run an audio stress-test at small ASIO buffer sizes, you'll find that Ryzen can't sustain heavy loads (glitch-free) at small ASIO buffer sizes (32-64 sample ASIO buffer size).

For working with audio, the 6900k will out-perform the 6950k.
The 6950k has two additional cores... but is running 500MHz slower.
If you know what you're doing, you can lock the 6900k at 4GHz.
Not over-clocked... and a nice speed boost over the 3.2GHz displayed in the Passmark results.  ;)

For working with audio, Xeon CPUs bring *zero* benefit to the table.


In short, it's not Windows... it's the machine and how it can (or can't) be configured.

Whether you prefer to use Win10 or OSX is subjective.
Neither Win10 or OSX is more (or less) prone to instability.

Many professional composers/engineers are now running custom PCs, because performance is killing the aging Mac Pro platform.
The Mac Pros are literally several generations (hardware wise) behind...
The beauty of a custom machine is you can make it *exactly* what the client needs.
ie: If the client needs 8 SSDs for disk-streaming sample libraries, you can do that cost-effectively.
To duplicate that with external Thunderbolt is *much* more expensive.

On a side subject, ever tried to swap out a boot drive in a current generation iMac?
We've got one here to support clients. Latest version with 27" 5k display and i7-6700k CPU
You have to literally peal off the whole glass display, swap out the boot-drive, then use double-sided tape to re-attach the display.
You've got one shot to get it right. Even for the super tech-savvy, it'll get your blood-pressure going.
A PITA to do something that should take 5 minutes. Well beyond a novice user (which means a trip to Apple Service).

admin

I was perusing KVR... and someone from Image Line had just posted a response that's very relevant to this topic.
https://www.thegearpage.net/board/index.php?posts/23732250/

From that Image Line post:

"Interesting conversation, and one we often have with our customers in conjunction with system vs DAW CPU load...two issues to consider:

Time-scales

The audio buffer size, 1 ~ 50 ms. While the operating systems CPU meter may show 30% utilization, over the last 1000 ms (system meters are around 1 sec integration), there may have been multiple occasions during that period where real-time audio processing experienced interruptions. Why? If real-time audio 'Mixer threads' (packages of work for the CPU), have to wait on other threads to finish, because they can't be multi-threaded (processed at the same time), the DAW may experience audio underruns, or at least very high internal CPU meter readings. At the same time, the OS may report low overall and or individual CPU utilization. The CPU could have done a lot more work than it did, if it had something else to do at the same time. The reality for audio processing is the CPU must often wait for program and system related tasks to complete before it can continue, and so, may struggle to keep up with the very high demands of realtime audio output (generating 44100 samples per second, on an ongoing basis, without an interruption of a single sample, 0.02 ms). Just why the CPU must 'wait' is all to do with logic:

The logic of audio processing

There are long lists of tasks that must be processed in sequence, and this means logically can't be simultaneously multithreaded. For example: Plugins must wait for instructions from the Piano roll and Playlist before they make sound. Effects must wait for the audio stream from upstream instrument plugins before they can process it. Further, it's not possible to parallel-process (multithread) instruments and FX that are on the same Mixer channel (their audio is mixed together), or even in the same Mixer routing pipe-line (when one Mixer track is linked to another and another, even FX processing has an order from top to bottom in the FX stack). Then, the Master Mixer track must wait for every instrument > mixer track > effect to be processed before it can process the audio through the Master effects. Logically, there is a lot of waiting, that is a natural and unavoidable fact of DAW music processing.

Think of a production line. This means the CPU may not be particularly busy, using all its cores and processing slots, yet it runs out of time to fill that tiny 5 ms audio-buffer because there was a lot of waiting for things that needed to be processed in sequence. It should be clear that fast processing is very important and this is not the same thing as multi-core processing. The best CPU is one that has enough cores to spread the work around AND can do the most work on a single core during each buffer time-slice. Which leads to our TIP: When comparing CPUs, look for the fastest single-core performance scores in a package with at least 4 physical cores. Most CPU benchmarks list single core performance. For example, the CPU Benchmark website lists the single core scores."

alexmcginness

I manage to keep the audio latency on my desktop system set to a buffer size of 64 and that is while running many cpu hungry VSTi's and VST plugins. How??
   I use server machines and two apps. Vienna ensemble Pro and FX Teleport. The server machines are all run thru a hub with ethernet cables. All the audio is piped into the main machine thru those cables and the servers handle the load leaving the main machine with my DAW virtually load free.
  Main Machine is a dual hexcore HP Z800 with 48 gigs of ram and the three servers are all dual hexcore machines, one with 72 gigs of ram and the others have 48 and 24 respectively. Most projects I only use one server. Refurbished machines like the ones Im using are cheap as chips now. The last dual hexcore I bought was $650 US.
VG-88V2, GR-50, GR-55, 4 X VG-99s,2 X FC-300,  2 X GP-10 AXON AX 100 MKII, FISHMAN TRIPLE PLAY,MIDX-10, MIDX-20, AVID 11 RACK, BEHRINGER FCB 1010, LIVID GUITAR WING, ROLAND US-20, 3 X GUYATONE TO-2. MARSHALL BLUESBREAKER, SERBIAN ELIMINATOR AMP. GR-33.

admin

Quote from: alexmcginness on July 06, 2017, 03:11:36 AM
I manage to keep the audio latency on my desktop system set to a buffer size of 64 and that is while running many cpu hungry VSTi's and VST plugins. How??

What make / model is your main audio interface ?

alexmcginness

Quote from: admsustainiac on July 06, 2017, 07:25:51 AM
What make / model is your main audio interface ?

Its a MOTU pci 424 with three 24 i/0 break out boxes.
  I keep the buffer setting at 64 for tracking and midi. When Im mixing I set it to 256. Ive got tons of headroom using server machines and Vienna ensemble Pro and FX Teleport. The Asio meter in Cubase 8.5 sits below 20%.
  The MOTU isnt the lowest latency system. That honor falls to RME, but I got a great deal on the initial 24 i/o purchase and I bought the additional two 24 channel breakout boxes used. So Im running 72 channels in and out for a lot less price wise than an equivalent RME setup with very useable latency.
VG-88V2, GR-50, GR-55, 4 X VG-99s,2 X FC-300,  2 X GP-10 AXON AX 100 MKII, FISHMAN TRIPLE PLAY,MIDX-10, MIDX-20, AVID 11 RACK, BEHRINGER FCB 1010, LIVID GUITAR WING, ROLAND US-20, 3 X GUYATONE TO-2. MARSHALL BLUESBREAKER, SERBIAN ELIMINATOR AMP. GR-33.