Audio interface suggestions needed! (Update: RME interface has arrived!)

Stuckfast

That's right, most native plug-ins don't add latency unless they use lookahead or convolution.

octatonic

stratman3142 said:

octatonic said:

Branshen said:

https://www.pro-tools-expert.com/production-expert-1/2017/12/15/case-study-technical-testing-of-audio-interfaces

One of the main selling points of the babyface pro for me is the ultra-low latency, but looking at this table, it does seem that the Focusrite technology (2nd gen scarlett) has caught up. The difference is marginal with the scarlett 6i6 even beating the babyface pro at 96KHz.

With ultra low latency, arguably there is no need for onboard DSP to process vocals for monitoring as you could just slap it on the track and monitor with the effect added in the DAW. Food for thought..

And now my head has been turned by the ZOOM UAC-8.. 

Yes but once you start stacking effects up over the course of a project latency will be increased.

I still wouldn't buy an interface without hardware monitoring unless it is based around Pro Tools HDX.

I'd assumed (possibly mistakenly) that a VST didn't add latency if it reported 0/0 spls in Reaper. I haven't noticed an issue with my Zoom UAC-2 when stacking VSTs reporting 0/0 spls.

I don't use regularly Reaper, but all native DAW's use the same system, for processing audio- you have an audio buffer of X samples (lets say 128) plus the time it takes for the audio to convert from analogue to digital and back from digital to analogue.
the buffer sits between the A->D and D->A stages.

When a plugin is instantiated, if it is light enough to be able to process all the audio within the buffer size then no additional latency will be added.
As your project grows in size your buffer will need to grow because there will not be enough processing power to process all the audio inside the buffer time- this is why you get a 'tearing' type sound.

It is why, as you grow the session, from being a 'tracking' methodology (with a low buffer) to a mixing methodology (with a higher buffer). The higher the buffer, the more latency.

Say you are 80% the way through mixing a track and you want to add an overdub.
You will likely have a much larger buffer (say 1024 samples) in order to provide enough processing power, which would be around 23ms of latency plus converter latency. Without hardware monitoring you would need to deactivate a load of plugins in order to be able to lower the buffer to something useable.

Hardware monitoring is very useful in this situation because you can pull a sound using outboard and overdub with no perceivable change in the session or issue with hearing yourself 23ms+ after you play a note, which would be very unpleasant.

If you are only ever using a DAW to run a couple of amp sims then it won't be an issue.
If you are trying to record and mix your own tracks then you will come up against this problem all the time- it is the reason why hardware monitoring exists.

Pro Tools HDX uses a different method (TDM/HD used multiplexing, but they use a different technology now) to minimise latency, so it is down under 0.8ms and you can stack plugins (up to a point). This is why HDX is a better solution for tracking bands compared to a native interface. Also cue mixes are easier to do.

Actually an analogue console is easier than all of these, but you lose the ability to recall your mix.

stratman3142

@octatonic Thanks for that explanation. 

So I guess it's related to the computer power.  I haven't yet reached that stage where my computer has run out of power, with what I would regard as some pretty big projects, but perhaps not as big as some use.

Stuckfast

There are two buffers, one on the input side and one on the output side -- these are nearly always set to the same value. So the theoretical lowest possible round trip latency is equal to the converter latency plus 2x (buffer size / no of samples per second). For example if your buffer size is 1024 and your sample rate is 48k the theoretical latency is 2x(1024/48000) which is 42.7 milliseconds. Converter latency is usually sub 1ms these days so tends to be relatively insignificant except in situations where you're using two different converters with one interface, in which case signals that are split across the converters won't quite be in sync any more.

However, no interface actually achieves the theoretical latency because they all add extra safety buffering, which isn't always reported to the DAW.

Whether or not a plug-in adds latency has nothing to do with the buffer size. There are some very complex plug-ins that operate with no latency and simple ones that can only work by delaying the signal and thus adding latency. However what @octatonic is alluding to is that both adding native plug-ins and operating at low buffer sizes impose a load on the CPU, so a buffer size that might be fine for basic tracking can be problematic once you have more plug-ins in the project.

octatonic

stratman3142 said:

@octatonic Thanks for that explanation. 

So I guess it's related to the computer power.  I haven't yet reached that stage where my computer has run out of power, with what I would regard as some pretty big projects, but perhaps not as big as some use.

Yes it does, but also code efficiency and whether it is oversampling etc.
The more cores you have generally the better it will be too, rather than going purely for speed.

The last thing I mixed was 80 tracks with upwards of 200 plugins- even on a beast of a Mac it isn't possible to mix that at a 32/64/128 buffer size. 512 or 1024 only.

I mostly track with HDX though and then switch over to native for mixing, because my Mac is way more powerful than 2x HDX cards are, but there is no way a native system can come close to the latency I get with HDX once I have a bunch of plugins instantiated.

Stuckfast

@octatonic have you tried disabling hyperthreading with Pro Tools? Some say it improves efficiency and avoids the dreaded CPU spikes.

octatonic

Stuckfast said:

@octatonic have you tried disabling hyperthreading with Pro Tools? Some say it improves efficiency and avoids the dreaded CPU spikes.

I haven't but I don't get CPU spikes.
HDX is pretty stable for me and I have many cores.

Branshen

Thanks all. point taken about increasing latency with larger projects. I do my own tracking and mixing so that will become a problem. 

So... the RME babyface gives stable drivers for windows, basically guarantees low latency, DSP for hardware monitoring, and is even bus powered so I could potentially use it with my band as well without having to bring any additional power supplies. I will have a read of the manual to see how easily it's I/O can be used for external effect inserts. 

octatonic

Branshen said:

Thanks all. point taken about increasing latency with larger projects. I do my own tracking and mixing so that will become a problem. 

So... the RME babyface gives stable drivers for windows, basically guarantees low latency, DSP for hardware monitoring, and is even bus powered so I could potentially use it with my band as well without having to bring any additional power supplies. I will have a read of the manual to see how easily it's I/O can be used for external effect inserts. 

Make sure you check out input/output alignment.

I seem to remember there is a 3db difference with some RME audio interfaces.
Not an issue for recording but for hardware inserts you will need to compensate.
If you use Logic you can preprogram a preset with the IO plugin to compensate but there is no way to do it in Pro Tools other than manually.
Not sure about other DAW's.

Stuckfast

How much of a problem is that in practice, if you always use the hardware processors in the same configuration? After all most hardware units have some sort of input and output level controls that can be used to compensate I'd have thought.

Branshen

@octatonic would appreciate if you could help decipher some of these specs.. The top specs are the specs for the line ins on the side, whereas the bottom specs are the specs of the headphone outs (I'm thinking of using the 6.3mm ones.. The impedences are different but the dB is +13dBu for both. Is that ok? 

AD, Line/Instrument In 3-4

As Microphone/Line 1-2, but:

x Input: 6.3 mm TS jack, unbalanced

x Input impedance: 1 MOhm

x Signal to Noise ratio (SNR): 114 dB RMS unweighted, 117 dBA

x Frequency response @ 44.1 kHz, -0.1 dB: 5 Hz – 20.8 kHz

x Frequency response @ 96 kHz, -0.5 dB: < 3 Hz – 45.8 kHz

x Frequency response @ 192 kHz, -1 dB: < 2 Hz – 92 kHz

x Maximum input level @+4 dBu, Gain 0 dB: +13 dBu

x Maximum input level @-10 dBV, Gain 9 dB: -5 dBu

DA, Phones 3/4

As DA Line Out, but:

x Output: 6.3 mm TRS jack, unbalanced

x Output impedance: 10 Ohm

x Output level at 0 dBFS, 1 kOhm load: +13 dBu

x Max power @ 0.1% THD: 50 mW
x Output: 3.5 mm TRS jack, unbalanced

x Output impedance: 2 Ohm

x Output level at 0 dBFS, 1 kOhm load: +7 dBu

x Max power @ 0.1% THD: 70 mW

octatonic

Stuckfast said:

How much of a problem is that in practice, if you always use the hardware processors in the same configuration? After all most hardware units have some sort of input and output level controls that can be used to compensate I'd have thought.

It depends on how much hardware, what hardware you have, and how often you do it.
I have 64 channels of IO, a lot of hardware and I'm mixing in a hybrid style- so for me it was a total pain in the ass.
In the case Pro Tools and the Red 4/8Pre's 9db difference it meant instantiating 2 trim plugins because you can't get 9db out of a single trim plugin- less of an issue with Logic because you can save an IO level difference in a preset.

It isn't so much of a problem with compressors because of make up gain, but still why have to use make up gain and introduce noise when having parity input/output alignment takes away a step.

With EQ's, especially 500 series EQ's, it is a pain because you often don't have makeup gain controls.
Outboard effects will often have controls but see above re introducing unnecessary gain stages and noise.

I'm not saying he shouldn't buy the Babyface Pro because of this, but if using insert effects it is something to consider.

Branshen

At the moment. The only gear I have which I plan on using outboard is my moogerfooger low pass filter. But I do plan on adding to that (slowly).. 

octatonic

Branshen said:

@octatonic would appreciate if you could help decipher some of these specs.. The top specs are the specs for the line ins on the side, whereas the bottom specs are the specs of the headphone outs (I'm thinking of using the 6.3mm ones.. The impedences are different but the dB is +13dBu for both. Is that ok? 

AD, Line/Instrument In 3-4

As Microphone/Line 1-2, but:

x Input: 6.3 mm TS jack, unbalanced

x Input impedance: 1 MOhm

x Signal to Noise ratio (SNR): 114 dB RMS unweighted, 117 dBA

x Frequency response @ 44.1 kHz, -0.1 dB: 5 Hz – 20.8 kHz

x Frequency response @ 96 kHz, -0.5 dB: < 3 Hz – 45.8 kHz

x Frequency response @ 192 kHz, -1 dB: < 2 Hz – 92 kHz

x Maximum input level @+4 dBu, Gain 0 dB: +13 dBu

x Maximum input level @-10 dBV, Gain 9 dB: -5 dBu

DA, Phones 3/4

As DA Line Out, but:

x Output: 6.3 mm TRS jack, unbalanced

x Output impedance: 10 Ohm

x Output level at 0 dBFS, 1 kOhm load: +13 dBu

x Max power @ 0.1% THD: 50 mW
x Output: 3.5 mm TRS jack, unbalanced

x Output impedance: 2 Ohm

x Output level at 0 dBFS, 1 kOhm load: +7 dBu

x Max power @ 0.1% THD: 70 mW

I'm not sure you can tell from the published spec for the RME.

Have look at the Focusrite one here:

https://pro.focusrite.com/category/audio-interfaces/item/red-16line

and then at the Red 8Pre:

https://pro.focusrite.com/category/audio-interfaces/item/red-8pre

In the case of the Red 16Line the 0dB reference level is switchable from +18 or +24dBu for both input and output.
In the case of the Red 8 Pro the 0dB reference level is +18dBu on output and +27dBu on input (so 9dB difference).

This is what I am talking about- many audio interfaces have this and it isn't a problem except if you use hardware inserts.
It isn't always a dealbreaker but it is something to be aware of and compensate for.

I'd ask RME directly, if you think it matters to you.
You can of course configure a test so you know what it is when you get it- just use an IO plugin with a cable going from output to input and throw a sine wave across it at -6dB.
If the meter drops to -9dB when instantiating the plugin then you have a 3db drop, so you know you have to compensate for 3db.

The reason I know about this is I bought a Red 8 Pre, experienced the problem and realised the input/output alignment difference and went and asked them- they were good enough to swap the Red 8 Pre out for an interface that has parity (the Red 16Line).

Branshen

@octatonic ;Cheers for the detailed response. The level disparity is probably not going to be a deal breaker but I'll check around again and maybe even ask RME before committing.

WiresDreamDisasters

Stuckfast said:

That's right, most native plug-ins don't add latency unless they use lookahead or convolution.

This isn't true I'm afraid. A lot of plugins will add latency. It's just the nature of the beast.

Checkout Black76 by IK Multimedia for example. Every instance adds 64samples of latency.

Stuckfast

WiresDreamDisasters said:

Stuckfast said:

That's right, most native plug-ins don't add latency unless they use lookahead or convolution.

This isn't true I'm afraid. A lot of plugins will add latency. It's just the nature of the beast.

Checkout Black76 by IK Multimedia for example. Every instance adds 64samples of latency.

It is absolutely true. It's also true that a lot of plug-ins do add latency. That's cos there are a huge number of plug-ins in the world.

My Pro Tools system reports Black 76 as having a latency of 3 samples not 64, but an 1176 emulation is a special case. The hardware actually has an attack time that's faster than a single sample at base sample rates, so I guess it's necessary to use lookahead to emulate its behaviour properly.

WiresDreamDisasters

Stuckfast said:

WiresDreamDisasters said:

Stuckfast said:

That's right, most native plug-ins don't add latency unless they use lookahead or convolution.

This isn't true I'm afraid. A lot of plugins will add latency. It's just the nature of the beast.

Checkout Black76 by IK Multimedia for example. Every instance adds 64samples of latency.

It is absolutely true. It's also true that a lot of plug-ins do add latency. That's cos there are a huge number of plug-ins in the world.

My Pro Tools system reports Black 76 as having a latency of 3 samples not 64, but an 1176 emulation is a special case. The hardware actually has an attack time that's faster than a single sample at base sample rates, so I guess it's necessary to use lookahead to emulate its behaviour properly.

Reaper reporting 64 samples here. And it gets larger the bigger a buffer size for your audio interface you have. I can go through all my plugins if you want, but suffice to say, it's rare for a plugin to *not* add some sort of latency, even if it is only 3samples. It all adds up.

octatonic

WiresDreamDisasters said:

Stuckfast said:

WiresDreamDisasters said:

Stuckfast said:

That's right, most native plug-ins don't add latency unless they use lookahead or convolution.

This isn't true I'm afraid. A lot of plugins will add latency. It's just the nature of the beast.

Checkout Black76 by IK Multimedia for example. Every instance adds 64samples of latency.

It is absolutely true. It's also true that a lot of plug-ins do add latency. That's cos there are a huge number of plug-ins in the world.

My Pro Tools system reports Black 76 as having a latency of 3 samples not 64, but an 1176 emulation is a special case. The hardware actually has an attack time that's faster than a single sample at base sample rates, so I guess it's necessary to use lookahead to emulate its behaviour properly.

Reaper reporting 64 samples here. And it gets larger the bigger a buffer size for your audio interface you have. I can go through all my plugins if you want, but suffice to say, it's rare for a plugin to *not* add some sort of latency, even if it is only 3samples. It all adds up.

This was essentially my point- the cumulative latency of lots of plugins creates a scenario that requires hardware monitoring to get around it, or a multiplexing DSP solution like Pro Tools HD.
Or an analogue console.

WiresDreamDisasters

octatonic said:

WiresDreamDisasters said:

Stuckfast said:

WiresDreamDisasters said:

Stuckfast said:

That's right, most native plug-ins don't add latency unless they use lookahead or convolution.

This isn't true I'm afraid. A lot of plugins will add latency. It's just the nature of the beast.

Checkout Black76 by IK Multimedia for example. Every instance adds 64samples of latency.

It is absolutely true. It's also true that a lot of plug-ins do add latency. That's cos there are a huge number of plug-ins in the world.

My Pro Tools system reports Black 76 as having a latency of 3 samples not 64, but an 1176 emulation is a special case. The hardware actually has an attack time that's faster than a single sample at base sample rates, so I guess it's necessary to use lookahead to emulate its behaviour properly.

Reaper reporting 64 samples here. And it gets larger the bigger a buffer size for your audio interface you have. I can go through all my plugins if you want, but suffice to say, it's rare for a plugin to *not* add some sort of latency, even if it is only 3samples. It all adds up.

This was essentially my point- the cumulative latency of lots of plugins creates a scenario that requires hardware monitoring to get around it, or a multiplexing DSP solution like Pro Tools HD.
Or an analogue console.

Yep. It's one of the things that made me get the UA Apollo unit. Now I can monitor through effects when tracking, with no latency (or at least minimal) via the Console application, then in the mix I've still got RAW recordings. Since at FX we have some UA units anyway and a bunch of plugins, it made sense for me to go that route.

The UA Distressor is AMAZING on drums and vocals.