|
Post by stormymondays on Feb 27, 2019 16:06:01 GMT -6
Somebody suggested a new thread about I/O and latency, so I thought I'd open it. I've also decided to throw in some dither for good measure! I've read a ton of threads discussing inter-sample latency and the need to dither 24-bit streams. This is very relevant to anyone doing hybrid mixing, and I think there are quite a few of us that do that. Here's my take on it. I'm using Logic Pro X with the internal mixer set at 64-bit. RME Fireface 802 interface, plus Focusrite Clarett Octopre (via ADAT), all working at 44.1 and/or 48kHz. I/O latency: Logic's I/O plugin is great with its 'ping' feature. The RME interface has some voodoo going on behind the scenes and it always reports 0 samples latency. Everything lines up perfectly. The Focusrite can differ by up to one sample depending on whatever. I did have a big problem where it would have wildly different latency on every reboot, and got Focusrite to write new firmware for it that fixes it. I'm a bit proud of that! As far as I can tell, the latency reported by Logic is always correct. I've tested it sending pulses and recording them back - all good! Now, inter-sample latency: not a problem in my setup either. I know it's a problem for some, and I believe it could be related to older converters. I've read an explanation by Paul Frindle who says that essentially all current converters oversample so much that intersample latency can't possibly happen. It might be true or not, but I hear no smearing at all when doing parallel processing with my set up. Logic's I/O plugin even has a wet/dry mix so it takes a second to test. And then there's the whole dither debate. I know some people hear a definite improvement when putting a dither plugin before any I/O. The reasoning behind it is that the internal 32-bit (or 64-bit) is truncated to 24-bit, so it needs dither. In my setup, with my ears, dither makes zero difference. I'm using Goodhertz's dither plugin by the way. I've opened my latest mix which has 14 I/O sends-returns for external processing, bounced it with and without dither and compared the bounces. I can hear no difference between them, except perhaps a tiny little bit more noise on the dithered one. Even when boosting the highs severely and listening to the song's fade out I can hear zero crunchiness. I can still remember the sound of quantization distortion from the days of 16-bit Pro Tools and 882 converters (ugh!!!), so I'm pretty sure I know what to listen for. So that's my experience, with my setup and my ears: I don't dither to 24-bit and I don't fear inter-sample latency. I'm sure drbill and Bob Olhsson can chime in with the exact opposing view. Maybe it's a Pro Tools thing? A converter thing? It could also be my ears...
|
|
kcatthedog
Temp
Super Helpful Dude
Posts: 15,840
Member is Online
|
Post by kcatthedog on Feb 27, 2019 18:03:45 GMT -6
I use logic too and have 14-16 channels of ob io.
I hardly ever dither and like you think things seem clear, not aware of issues.
|
|
|
Post by svart on Feb 27, 2019 19:02:15 GMT -6
I don't worry about it. It's just fluff people get spun up over, but it rarely makes much difference overall.
|
|
|
Post by cyrano on Feb 27, 2019 19:04:21 GMT -6
There simply is no such thing as "inter-sample latency".
|
|
|
Post by Tbone81 on Feb 27, 2019 20:00:44 GMT -6
Cubase 9.5 here, works much like logic in that the I/o plugin has a ping feature. Weird thing is that I can get different values if i ping more than once. I never parallel process so it’s never been an issue and it usually alternated between two values so I just pick the one that comes up most often. I Don’t dither either even though I’m sure it’s technically correct to do so.
I usually have 8 channels of hardware inserts, running 24 bit, 48 k.
|
|
|
Post by christopher on Feb 27, 2019 21:45:04 GMT -6
I would think a single multi-IO chip- like the cheaper interfaces use- probably behave better at this. When you have lots of seperate IO chips all speeding up/slowing down to stay locked to a master clock, I bet issues could be there.
|
|
|
Post by Mister Chase on Feb 27, 2019 22:05:33 GMT -6
Use tape.
|
|
|
Post by drbill on Feb 27, 2019 23:44:38 GMT -6
There simply is no such thing as "inter-sample latency". How so?
|
|
|
Post by drbill on Feb 27, 2019 23:45:55 GMT -6
Haha!! Yup!! No inter-sample latency there!!! <thumbsup>
|
|
|
Post by drbill on Feb 27, 2019 23:55:13 GMT -6
Bob is the dither expert. I dither when I've got the time and inclination. If I'm rushed and speeding to finish some music, I'll probably be lazy and not dither. Sometimes I can tell a difference, and other times I can't. It seems to depend quite a bit on the piece of music. I generally use the dither in FF's ProL. It's pretty sweet. Almost sounds "EQ'd" to me sometimes.
As for : Intersample latency.... It exists. It's physics. Ask Michael Brauer. Of note : the higher your sample rate, the smaller the error, and the less likely it will bother you. But, different interfaces, drivers, etc. all come into play here. One system running at 192k may be dead on, or close enough that it doesn't matter. Another system running different interfaces @ 44.1 could me a phasey smear. It's all relative to your system, it's round trip timing, and physics.
However, if you're not parallel processing, it's essentially a non issue. I mostly parallel process with analog gear that has a "mix / blend" function. Makes it super simple. I mostly DON'T parallel process with gear that doesn't have it. I dunno, back in the day with 2" tape and 24-32 channel consoles, we didn't have the resources to "parallel process" everything. It's a useful tool, no doubt, but a bit over rated IMO.
For me, delay compensation / latency compensation is brainless. HDX2 here, and it's a simple as enabling it in PT and forgetting about it. No pinging, guessing, or picking the one compensation amount that's "in the middle". BUT, it cannot compensate for the time between samples.... Some can hear it, some can't, some care, some don't. Pick your poison and make music.
The basics for me currently : PT12.x, HDX2, MacOS, 96 Channels of HD i/o, tons of outboard on PT inserts for every mix - NO parallel processing happening between the analog world and my DAW tracks - it (parallel) all happens before it returns to DAW land.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Feb 28, 2019 2:30:25 GMT -6
Always dither to the analogue chain here. Made a difference in my listening tests. Also, as Bob will chime in I'm sure, these truncation errors accumulate down the line. Might not be apparent if you don't dither once, but if it happens a few times in the recording, mixing, mastering and playback chain, they will accumulate, they will become audible, and dither would have prevented that, so why not use it? Best practise and all that.
|
|
|
Post by stormymondays on Feb 28, 2019 2:58:14 GMT -6
Always dither to the analogue chain here. Made a difference in my listening tests. Also, as Bob will chime in I'm sure, these truncation errors accumulate down the line. Might not be apparent if you don't dither once, but if it happens a few times in the recording, mixing, mastering and playback chain, they will accumulate, they will become audible, and dither would have prevented that, so why not use it? Best practise and all that. I’m all for best practices but also for reality. I’m sending out of the box 14 truncated 24-bit streams in individual channels. Some of those are truncated twice, because some drums are processed individually and then go to the drum buss. Lastly the master buss is sent out again. That’s a lot of accumulated errors that should be easily audible. In my system, tested by me, with real music, there is no truncation noise. So in my case, the “best practice” is to trust my ears - and trust that the designers of Logic know more about digital audio than I do By the way, RME publicly and proudly claim that their interfaces truncate to 24-bit, by design and purposefully.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Feb 28, 2019 3:02:22 GMT -6
For sure, if you can't hear the difference then it doesn't exist.
|
|
|
Post by stormymondays on Feb 28, 2019 3:04:14 GMT -6
For sure, if you can't hear the difference then it doesn't exist. I should have kept my test bounces and send them to people to listen on their own systems. I deleted them after the experiment though I might do it again on another mix.
|
|
|
Post by svart on Feb 28, 2019 8:45:22 GMT -6
There simply is no such thing as "inter-sample latency". There isn't. It's called jitter.
|
|
|
Post by christopher on Mar 1, 2019 12:12:38 GMT -6
I trust you on this Svart! So I can't help but have some super nerdy questions:
When I think of "jitter" I think of time domain variance that is exactly like wow/flutter. Clocking variance.
The word "latency"... makes me think of something like a buffer storing a value and reporting it late.
Ok so here's where things get deep for me:
My understanding of sampling is that (correct me wherever wrong)
- the AD converter measures input as + or - voltage, (same way an ACVM does?) and assigns that voltage to a bit value. In my simplistic 'sound-guy terms', this only tells us how "loud" the sample is, and whether it is positive or negative.
- the oversampling-converter samples at a VERY high frequency for the duration of the sampling period. It only stores and converts only the highest voltage during the entire sampling. (Q: would a loud 32kHz analog peak cause an error here? Food for thought...)
- the Nyquist filter: This is just a low pass filter, which filters out any garbage that is due to 'trying' to capture sound above nyquist. OK... so here is where that error can possibly be corrected, as any error between the samples would be from a signal above Nyquist, ie that 32kHz peak I talked about.
BUT----------
I might argue that since it is only voltage the Nyquist sees( not a frequency) IF that 32k peak "error" voltage combines with samples before/after that error, isn't it possible that the error wouldn't get filtered out by the Nyquist filter?
Ok I should stop here in case my sampling understanding is totally wrong. Its a deep topic I only learned by reading some spec sheets for IC's, and its not in simple language.
|
|
|
Post by svart on Mar 1, 2019 13:25:51 GMT -6
I trust you on this Svart! So I can't help but have some super nerdy questions: When I think of "jitter" I think of time domain variance that is exactly like wow/flutter. Clocking variance. The word "latency"... makes me think of something like a buffer storing a value and reporting it late. Ok so here's where things get deep for me: My understanding of sampling is that (correct me wherever wrong) - the AD converter measures input as + or - voltage, (same way an ACVM does?) and assigns that voltage to a bit value. In my simplistic 'sound-guy terms', this only tells us how "loud" the sample is, and whether it is positive or negative. - the oversampling-converter samples at a VERY high frequency for the duration of the sampling period. It only stores and converts only the highest voltage during the entire sampling. (Q: would a loud 32kHz analog peak cause an error here? Food for thought...) - the Nyquist filter: This is just a low pass filter, which filters out any garbage that is due to 'trying' to capture sound above nyquist. OK... so here is where that error can possibly be corrected, as any error between the samples would be from a signal above Nyquist, ie that 32kHz peak I talked about. BUT---------- I might argue that since it is only voltage the Nyquist sees( not a frequency) IF that 32k peak "error" voltage combines with samples before/after that error, isn't it possible that the error wouldn't get filtered out by the Nyquist filter? Ok I should stop here in case my sampling understanding is totally wrong. Its a deep topic I only learned by reading some spec sheets for IC's, and its not in simple language. Good thoughts. Jitter is a catch-all term for clock cycle inaccuracy. We tend to colloquially use the term for faster clock cycle inaccuracy, and for slower, we call it "wandering", but it's the same thing overall. Jitter and clock cycle inaccuracy can be broken down into parts. We can have deterministic jitter which is jitter than has known boundaries in speed and frequency, and is typically caused by something external, such as noise from a power supply. You can also have random jitter, which is exactly as it's name suggests and has no known external causation. When folks in this thread mention "inter-sample latency" they really mean "sampling jitter" which is the inaccuracy of the sampling timing due to clocking inaccuracies. It's a mix of random and deterministic jitters with the random jitter causing more white(broadband) noise and deterministic jitter causing more harmonic anomalies. ADC's do indeed measure a peak voltage at the clock edge via a sample/hold circuit. This voltage is naturally variable over frequency based on the ADC's analog input bandwidth, which is generally specified in the datasheets, and usually higher than the ADC sample rate can capture to ensure frequency flatness in the capture band. The Nyquist filter, in layman's terms, reduces the input bandwidth so that signals at multiples of the sample frequency above the samplerate are not mixed down into the capture bandwidth. Sometimes you do want to be able to capture above the samplerate, which is why the filter is usually external. We don't use it in audio, but in RF it's common and it's typically called super-nyquist sampling or sometimes called undersampling. Since frequency transients with rise/fall times that are faster than the sample rate are mathematically the same as being higher frequency, the Nyquist filter will effectively filter them out, but this is limited by the physical attributes and type of the filter used.
|
|
|
Post by javamad on Mar 1, 2019 15:02:18 GMT -6
(I think) this is where us hybrid summers don’t have to worry...
My 16 outs from my 2 Apollos are locked in and I do parallel processing but post DAC and sum back into my summing rig then it all gous back into a stereo ADC pair.
Simples! :-)
|
|
|
Post by Guitar on Mar 1, 2019 17:02:37 GMT -6
I don't worry about it either.
|
|
|
Post by Bob Olhsson on Mar 2, 2019 11:36:28 GMT -6
I'm hardly a dither expert.
I have experienced that truncation distortion accumulates and at some point the audio becomes crunchy sounding. Randomizing the bottom bit prevents that distortion. It doesn't just cover it up with noise. I also don't hear a difference from one pass of 24 bit dither unless there is a significant amount of room tone involved such as a string section. In that case the truncation distortion will mask the low level information that we perceive as depth.
I talk about dither a lot because failure to dither and cheap analog stages that don't have enough headroom are the main causes of what everybody hates about digital sound.
|
|
|
Post by cyrano on Mar 2, 2019 19:00:50 GMT -6
There simply is no such thing as "inter-sample latency". There isn't. It's called jitter. I don't know who invented the phrase, but it is marketing speak. there simply can be no latency between samples. Clocks simply aren't that bad. You might as well worry about bit errors in ram. There's one every 20 microseconds in an average PC. So there are some in your audio. But being off by one bit isn't audible. And even jitter isn't something to worry about, unless you're clocking a lot of AV gear over long cables, like in a movie stage.
|
|
|
Post by christopher on Mar 2, 2019 23:38:59 GMT -6
After thinking about it, it makes sense that It could be related to timing. Not easy to explain... a high frequency wave can be shifted by as much as 1/2 sample in the time domain. At standard low freq rates there’s not enough samples to accurately display wavehapes, so at best highs are captured as square or jagged triangle waves. The filter strips out the overtones so that all highs become sine waves on test equipment. But the peak of that sine wave technically wouldn’t be in the exact same location as an analog wave. ...and so the extreme highs could potentially be shifting around all over the time domain, by as much as 1/4 a cycle.. (e: might be up to 1/2 cycle diff if two mults are captured)
|
|
|
Post by cyrano on Mar 3, 2019 19:57:16 GMT -6
You've been reading hifi magazines again, haven't you?
A clock is an extremely simple thing. It either locks, or it doesn't. No speeding up or slowing down. When it locks, it works. It's just when it's on the border of working/not working thar audible artefacts can be produced. But that usually doesn't last long because you'll notice the crackling and stop recording or playback.
Jagged waveforms don't exist in the normal range an ADDA is built for, as they get smoothed out. But it's a very old adagio used to sell esoteric high-end gear.
That's the major advantage of digital: it's simple. It either works or it doesn't.
|
|
|
Post by christopher on Mar 5, 2019 12:27:09 GMT -6
I get what you are saying, this is super nerdy and really for probably 99.999% of everything audio this stuff doesn’t matter at all, not audible to most so who cares. But for some situations where maybe someone worked hard on the perfect tone for a perfectly harmonious upper “sizzle” that blends sweetly in analog, maybe they aren’t getting that same exact sweet “sizzle” when blending ITB? There might be some technical things that may at the root, jitter is known.. this “intersample latency” term though.,, wtf? But then i thought about it and there’s something to it maybe: A sinewave at 1/2 the sample rate is easiest to imagine an issue; the sample hold will only record the peak+ and peak-, and represent it as a square wave on the ‘stairsteps’... the oddly named “reconstruction filter” doesn’t build the wave. It’s just a lowpass filter, it lowpasses and destroys the stair’s-square wave so that the only harmonic left is the fundamental sinewave (which is smooth and perfect yes). Perfection and genius so far.. Again for a sinewave exactly 1/2 sample rate: here’s where the problem is: the sample/hold can only save the voltage of the peak, it cant tell us where the peak was. The peak happened sometime between beginning, and end, of the clock cycle. BUT after “reconstruction” the peak can only be in one place: halfway through the sample period, right where it should be, 90 degree point of the start of the sine. HOWEVER.. the analog peak could be anywhere between 1-180 degrees during the sampling period.. the sampled version will only be at 90 degrees. At exactly 1/2 sample rate, there’s a lot of room for phase slippage in the time domain (+/- 90 degrees worth! ) ,... but what about waves just below 1/2 rate? Well they too have only 2 samples and then every once in a while a 3rd sample. So they will have the same issues, but less room to slide around before/after the reconstruction filters’ placement. So not a full +/-90 degree slippage, because that extra sample every so often narrows the slip by some amount. As we get more and more samples to represent the wave, there is less room for the phase-slip (intersample latency seems like a pretty good term?) For me when I look at this, the whole upper octave before 1/2 the sample rate is suspect. Not that it matters intensely, I just need some “sizzle” from that range. But maybe knowing this I can improve my workflow a little help the quality of that sizzle to the recording? Of course I could be totally wrong here (which I’m fine with), so.. hey
|
|
|
Post by drbill on Mar 5, 2019 12:54:19 GMT -6
Im' not sure whats so difficult to understand. All of this is in regards to processing ITB signals thru analog processing and recombining the "dry unprocessed" (ITB) signal with the "wet processed" OTB processed signal - INSIDE THE BOX - not in the analog world before importing again. It's been diagnosed and confirmed by engineers that are 1000X's smarter than I am.
Inside the DAW, all audio is chopped into "samples". 44,100, 48,00, 96,00 etc. per second. It's not an analog world, there are gridded discrete steps and the audio starts and ends on a discrete step. The higher the sample rate, the smaller the chunks of those steps are, and the smaller the slots in between them are. The lower the sample rate, the larger the amounts of time between the grid of the sample start.
Even in DAW's with interfaces that are consistent with the system every day, the delay compensation to get those analog signals out the DA and back into the AD "in sync" are not always the same. ie: delay compensation may be 3 samples on Tuesday, and on Wed morning, might be 4 samples. To make it a little more complicated, Interface A can have a different "round trip" time in samples than Interface B. Fact. That's why we have the pinging and delay compensation - to ascertain exactly what the round trip time is in samples. Otherwise all software DAW's would have a fixed delay compensation time, and all would be fine.
Once you leave the D/A and go into the analog world, it's going to take (usually) a fixed time to exit your DA and go thru the analog chain you have and get back to the input of your A/D. Do you believe that once in the analog world that you will come back in perfectly "on the sample grid". That would be a nice happy world. My experience is that it doesn't happen. But that is exacerbated due to the fact that I generally work at lower sample rates, and my interfaces fall in the cracks bringing the analog processed signals back in.
If your answer is yes to all audio comes back into the DAW perfectly on the grid, then there is no inter-sample latency.
If your answer is "maybe or no or I don't know" then the chance of inter-sample latency exists. As I mentioned, the higher your sample rate, the smaller the difference, and the less it matters. The slower your sample rate, the larger the hole that the analog signal can "slip" into once it's re-digitized.
This is a well documented issue with DAW's. Especially as they are used to blend ITB dry and OTB wet signals.
PS - in retrospect, thinking about it, perhaps the term "inter sample latency" is misleading. (I didn't coin the phrase) Obviously there IS no "between" samples in the DAW - everything is gridded to a discrete sample. What happens in real world hybrid mixing, is that once re-digitized, the analog affected incoming audio does not always (does not usually) "line up" with the leading edge of a transient that has been analog processed in a round the loop DA/AD fashion matching the leading edge of the unprocessed ITB transient. Hope that makes better sense.
|
|