delay on aux sends

[antoniodelrio]

Hi all,

I just discovered some weird behavior on aux sends. They send audio with an audible delay. To be more precise, 80 samples delay at 48khz. So if you are trying to do paralel compression, this delay is noticible.

Is it normal??

[Y-my-R]

I haven't noticed, but rarely go to compressors via the aux sends, so I wouldn't know.

80 Samples at 48 kHz sounds like a lot, though (I don't want to do the math now, but that should still be well under 10 ms... can't hear that, unless you get phasing or something, when parallel processing... but by itself, I don't think that'd be noticeable).
I do expect that it will take the D8B "a couple of samples" to route signals to places, and especially to process anything via a DSP... but I'd expect that this would be in a range of maybe around 10 samples, give or take... 80 Samples seems too much (but then again, I don't know if "old technology" like the D8B really was this slow... but I can't imagine that).

How do you measure? (i.e. if you measure from a computer with an audio interface, that interface's buffer/latency will add to the delay, and would have to manually be subtracted. Better to use a playback source that doesn't add a buffer, like, maybe an HDR would work for that, but I'm not sure... is that what you're using?)

[antoniodelrio]

The way I measured is simple enough. But before that I must say that I decided to measure it because I noticed the latency by hearing. BTW, I normally do parallel processing in-the-box in Samplitude, but I have a project were it would be nice to have the choice for parallel compression out-of-the-box.

Said so. Just plug a synth on channel 1 with a short click sound. Route channel 1 to bus 1 and send to aux 1. Both signals routed through alt I/O ADAT and inserted in two channels on the DAW. Record. Measure. Thats it.

[Old School]

Hi,
80 samples at 48k is 1.6 milliseconds, just so you'll know.

Have a blessed day,
Mike

[Phil.c]

And that's a lot!

[Y-my-R]

Thanks, Mike!

Yeah, if it's 1.6 milliseconds, that's not noticeable by ear. I hear these "superhuman" stories often enough, but there must be a different reason.

So, where's that synth sound coming from, and how does it get into the D8B - and then you record it into an audio track in a DAW/Samplitude?

So, if the synth is triggered via MIDI the (short) time from sending the MIDI message and until a sound comes out, will also not be absolutely instant. It's normally neglectible, but if we're talking about the D8B taking 80 samples or not, even that delay matters for this kind of measurement. IMO, testing via MIDI trigger is not valid, since you don't compare a waveform to a waveform.

You need to compare a waveform that is being played back and recorded again, then eliminate anything else that is causing a delay (e.g. by subtracting the buffer in samples that the audio interface causes, from the delay/latency you observe), and then compare the difference of the placement of the audio on the track, between the original waveform and the re-recorded waveform.

So, whatever the buffer size is on the way OUT of the audio interface needs to get subtracted from the delay you observe - since that delay is caused by the audio interface and not by the D8B.

Technically, a delay is added both, on the way out of the audio interface AND on the way back into the audio interface...but on the way in, the audio interface should compensate for the delay the "input buffer" causes, by placing the audio that is being recorded by that much earlier on the audio track, as the buffer's size is.

So if the DAW does its job right, you should only have to deduct the audio interface's buffer size in samples once, and not twice (but when doing QA for this sort of thing years back, I observed that not all DAWs always properly placed the audio on the tracks at all buffer sizes... but that's a different story and hopefully doesn’t happen much anymore, nowadays).

...however, if you'd real-time monitor from the software while playing back audio and recording it again, you're looking at (aka listening to) double your audio interface’s buffer size as the delay, since during recording, what you hear can't be compensated for... it's only going to be placed correctly for the next playback AFTER recording. So, a configuration like this, would explain a clearly audible delay.

But then again… if you were triggering MIDI and monitoring through the D8B, there should be no “audio interface buffer” related delay – but then I still don’t undersand how you measure this in a way to get a meaningful result…?

So, how you you compare the original start point and the re-recorded start point? You’re not comparing a MIDI note with the placement of an audio recording, right? And if you do, did you at least subtract your audio interface’s buffer size from the result?

But anyway, at a practical example, if you had set a buffer size of 64 Samples for your audio interface (that's relatively small... can't go much lower on USB... would have to go Thunderbolt for anything faster than that), and you observe a 80 Samples delay from playing back a sample and where it gets placed on the track, then your “real” delay that was added by something else than the audio interface, would be 16 samples… and that would put us in the ballpark of what I’d expect from a hardware mixer like the D8B.

So, what’s your audio interface’s buffer size?


Also, what audio interface driver are you using with Samplitude? From my memory, it doesn't use ASIO by default, but uses it's own "Wave Driver" or something, that uses a pretty uncommon buffering method. It works surprisingly well for being based on the Windows WMA driver standard, but I’d still recommend to use an ASIO driver with Samplitude, if you’re not already doing that.

(I used to work for Magix/S'eKD back in Germany for a few years, back in the 90s). It's possible that delay compensation in Samplitude happens differently than elsewhere and thus the latency measurement would have to be done differently, not sure. Honestly, I didn’t understand buffers and delay compensation for recordings and plug-ins back then, ha).

Anyway… maybe I’ll do a measurement myself, but to do it right is a bit of a hassle… and for the types of “send” FX I sometimes use on the D8B (reverbs and such), a slight delay doesn’t really matter, so I personally don’t “need” that answer. But I’m curious now… if I get a chance, I’ll do a measurement, but don’t hold your breath

[Y-my-R]

...and after I typed all of this, I realized that your test looked very different, and actually is more valid that I what I'm saying above.

So, what you're really saying is, that the same source audio is being routed from a channel straight to the ADAT/Tape out versus a signal that is routed to a buss first and then sent to an analog aux send, are recorded in your DAW at different positions?
(If it goes into the analog and digital ins on the audio interface, respectively, this would also be something to look at - but technically, the audio interface should be compensating for any differing delays from different input types... and it shouldn't be nowhere near 80 samples... that's a lot).

...or does the signal that went to the Aux channel, somehow end up on the ADAT out...?

I'm trying to understand what we're actually comparing... a timing difference between a digital out and an analog out?

Or an apparent internal delay in the D8B, depending on the path the signal gets routed through?

Sorry... I'm a bit confused now... also sorry about the long non-applicable e-mail above. Just trying to figure out, what we're really looking at.

[antoniodelrio]

Step by step.
1. Thats it. 80samples are 1,6ms. (80 / 48000 = 1,6E-3)
2. 1.6 ms while doing parallel compression is noticeble. And if anyone is not able to hear it, he should train his ears.
3. Midi has nothing to do with this experiment. I hit record on the DAW and play my synth with my finger. I chose a click sound to be precise measuring the transient, but actually any drum sound could do the job.
4. I made a mistake in my last explanation. Routing both signals (bus1 and aux1) through alt I/O adat in deed doesn't produce any delay. Both signal arrive exactly in time.
5. Making more tests I discovered that the latency is coming from the D/A conversion (or so I think). Those are the tests i did.
My setup:
RME digiface and RME multiface. Thats 4x ADAT plus 8 analog inputs
Kurzweil synth with a pair of stereo balanced outputs.

a) one mono output from the synth pluged to analog input on multiface. The other one to channel on D8B and this routed to adat through route-to-tape. 1 sample delay measured ( probably due to the different technologies of ADC from RME and Mackie) Anyway this is negligible

b) one mono output from synth plugged to analog input on multiface. The other one plugged to channel on D8D and this send to aux1. Then aux1 analog output plugged to multiface analog input. 80 samples delay measured.

c) both mono outputs from synth plugged to a couple of channels on D8B. Channel one routed to tape through ADAT and channel 2 routed through bus 1,and this through ADAT to RME. No delay observed.

d) one mono output from synth plugged to D8B and routed to tape through ADAT. Additionally send to aux1 and this analog aux1 connected to multiface. 80 samples delay measured.

Said so, this could be a shared delay between ADC and DAC conversions, but since test a) showed no delay, I think it is more likely just the DAC playing this role.

[Y-my-R]

I think the methodology you used makes sense, and I agree with the conclusion, that the D-to-A conversion seems to be adding the delay.

And for the record, what I said further above, about the 1.6 ms of latency was this (quote):
"...can't hear that, unless you get phasing or something, when parallel processing..."

In other words, sure - with 80 samples of delay and the original and delayed signal going on at the same time, you'll have phasing happening (aka "hollow" or "thinner" sounding audio, due to partial phase cancellation).
What's "super-human" is to hit a note on the keyboard, have it come out with 1.6 ms of delay, and say "hey, that didn't come out right when I pressed the key."
Maybe if your name was Dave Weckl (my favorite drummer), I'd give it a second thought... but on average, I think people notice an "audible" delay from around 8-10 ms. If you're a GOOD drummer, then maybe from around 5-6 ms.
Your average guitar player would probably still be happy at twice that latency and wouldn't even know, hahaha...

Anyway... I'm sure we're talking about the same thing... without the presence of a second signal that is being impacted (e.g. phasing), I really don't think you will "notice" 1.6 ms of delay, when pressing a key on your keyboard.

As for the D8B causing 80 samples of delay on analog outs, that's pretty bad... makes me wonder if this is generally the DAC, or if there's any processing going on that might cause it (e.g. dithering or something).

It doesn't impact me much, personally, since my main use for the D8B is to send/receive 24 channels via ADAT from my DAW computer and I don't record through it, but mostly just monitor (and rarely use anything other than Reverb via the sends)... but I do agree with you, that if the D8B would cause 80 samples of delay on each of it's analog outputs, no matter what, it would make it difficult to use with any kinds of FX that require the phase to stay "true" - like any kind of parallel processing that isn't a delay or reverb, etc.

I might check it out if I get a chance, to see if this really happens across the board on the analog outs, or just on the (analog) Aux sends. Bad enough if it's just the Auxes... but REALLY bad if it's all the analog outs.

AFAIK, several people on here have their HDR/MDR recorders connected via Analog cards in the Tape I/O (I wouldn't do that because of the unnecessary conversions... but that's another story), so, I'd think that there's a chance that this kind of latency would then ALWAYS be present, just from the AD and DA conversions... did anybody ever check for that or observe something like that?

Very interesting find, antoniodelrio!

[antoniodelrio]

Well, at the end we were talking about the same. Anyway, I am not one of those superhumans feeling small amounts of latency. Indeed I use to play VSTi’s with up to 10 ms latency without feeling uncomfortable.

Coming back to our topic… I liked you mention dithering, ‘cause I tried it. And I can tell it makes no difference with or without UV22 dithering. Both ways produce the same ammount of latency, which actually make sense, since usually dithering process just adds floor noise to the signal (the process is a bit more complex, but at the end it is what it is)

But now, more seriously, I am feeling as discovering the wheel, since this topic was already covered long time ago. It is described that channel D/A processing has 85 sample latency as you can see in this chart

https://www.sonido-7.com/d8b/latency.html

85 samples for aux send, minus 6 samples from ADAT conversion, and here they are the 80 samples I measured.

And this is really weird, because if I add 80 samples delay to the channel strip, it affects to the aux sends as well, so, I cannot see how to compensate this limitation…

I’m a bit disappointed with this