ADAT to Scope PCI to Xite ADAT

[yayajohn]

If i run a signal from a converter to a Scope Pro ADAT in and route it directly into the Scope ADAT Dest then into Xite ADAT in, will there be any significant (audible) latency?

[dante]

I used to run Scope Pulsar PCI card ADAT to XITE-1D ADAT no latency - so I guess the only latency in your chain is the first converter going into the Scope Pro. i.e. negligable and anyway unavoidable. Also maybe (guesswork here) depends on your sample rate as well, the higher the sample rate the lower the latency.

[yayajohn]

Right! Hadn't thought about the UULI settings. So I guess @44.1 - 3ms into PCI +3ms into the Xite =6ms? (+Xite out to mixer to speakers to ears)
yeeesh, seems like an awful long way to travel when I write it out like that.
Will I hear that? I may have to rethink this although it will mostly be for effect return signals. Probably will make tempo sync delays nearly impossible.

[garyb]

the latency will be only a couple of samples. it's the same as connecting any digital hardware. latency is negligible. latency only exists in any significant amount when going through Windows and the sequencer. going from Scope to Scope has nothing to do with Windows or the sequencer.

[yayajohn]

Ok cool. Thanks

[valis]

Still important to correct this offset (a few samples) if you're doing parallel processing.

[garyb]

only for some music.
with hardware and real patchbays and mixers, those kinds of offsets are normal and part of why things sound great, sometimes...

computer nerds are funny sometimes. the spend a lot of money on things that are supposed to recreate the random nature of real gear, and then hours making sure that everything is sample accurate.

[valis]

Yes, I am indeed a computer nerd

[garyb]

heeheehee...

we're fortunate for that.

[fra77x2]

Some tips not related completely to the thread but about the "offsets"

Still important to correct this offset (a few samples) if you're doing parallel processing.

I strongly believe in this.

If you put ASIO in dsp 10 ( the enumeration fits the sdk, I think its "9" in the Scope software) and a mixer at dsp 10, and any effects on the same dsp (10) then you can do parallel processing with sample accuracy on any asio output. If you record the output of the mixer or the output of the effects you can put it back as audio in a daw channel and offset it -4 samples. Then the recorded file will be sample accurate to the "dry" audio.
i.e. asio output has 4 samples latency.

Reaper has the Nudge/set items window for this kind of adjustments.

In digital domain sample accuracy is a must if you do parallel stuff. Otherwise comb filtering artifacts come into play and ruin the performance of the devices. A sensible sound engineer will use a "dirac" i.e. a one sample impulse to test exactly the behaviour of the audio paths. (set your daw to display fully zoomed waveforms as stepped lines instead of interpolated curves so to see the actual samples).

[valis]

I concur, we can use a 1 cycle pulse when correcting things that I measure by recording the result back into the DAW (versus monitoring). Easy to draw your own. I don't use an impulse (1-cycle) when monitoring because I have a habit of trying to get decades out of my tweeters (/horns), and even with output filtering/protection this concerns me. But if you're visually comparing then impulses (as mentioned above) then this indeed great, and sometimes necessary depending on how much the device processing your audio is affecting your audio.

Fwiw, it's probably smart to do this when first wiring up effects send processors in the analog realm, as well as their SPDIF/AES sends. And there are procedures for measuring round trip and one way latency in the DAW (this sometimes matters when passing through external effects units etc). So why not Scope as well...

"Don't encourage him!" (is presumably what Gary is thinking). I jest...but I don't see this as a major deficiency.

Scope doesn't change that much in normal use, stereo pairs are fine with most devices (outside of the most dsp hungry). And if memory serves, 8-channel groupings on a mixer with phase compensation enabled also stay on the same dsp, though I forget if inserts do or not. GaryB can chime in on that front.

We can save DSP assignments now to some degree as well, I believe?

So most normal workflow deficiencies seem to be accounted for in modern versions of Scope, it's just with complex routing that I find myself paying more critical attention to the phase relationship. This imho just comes with learning a tool well...

And it's worth mentioning that it's still possible to 'break' most of the DAWs (ie, the "Automatic Compensation") by using exotic enough routing. Especially with external effects routing, as well as the fact that many of those packages add more & more stacking/grouping/layering options for their mixer/arrange page views (mixer groups, VCA groups, channel stacks etc). So those teams are busy trying to account for the silly nonsense people do when u continue to offer them options...and reading places like Gearslutz and other still active user arenas (audiobus forums are very active for instance) can reveal how many computer nerds there really are out there

In any case, sometimes I use my ears with a well defined enough sample source via the samplefix tool from Red_Muze aka Assaf that you can find here, which is simple to use by sending the 'normal' channel into input 1, and the 'effected' or parallel version of that into input 2. This of course requires 2 instances if you are correcting a stereo pair. Sometimes I do as mentioned above, and measure the result by recording directly into the daw. Sometimes it might also make sense use that initial starting cycle, and an ending cycle, with a Ramp in between. Depends on what is being tested..Ramp can show different axes of phase relationship. Or even other test tones, of course.

On the subject of Ramps..these can also be used to send control signals to many flexor devices. Though of a slightly different nature than the above workflows, Flexor & other full audiorate extensions can do wonders for scope use as well, in terms of precision of sound. Here we can use a Ramp from our DAW to drive our sequencers and and modulators (with flexor etc), and can 'chop' the ramp (though with certain effects this can make a glitchy mess) by editing the audio parts that contain the ramp loop. By using Val Monitor which can "monitor" the incoming values and convert it to non-audio rate control signals, and so on. Wandering more than a bit off topic here of course. But Phase may be important to certain 'precise' workflows, in short.

Going for sample accuracy in one domain (full audiorate tricks & modulators in Scope Modular), why then smear these transients events...same would apply to ADAT & analog i/o using complex signal routing, which I sometimes do. And used more typically, I find scope very precise.

[fra77x2]

This (what I previously wrote) does not concerns particularly scope but any digital interface.
The one sample pulse is harmless for the monitors but they are just for testing purposes better observed graphically no reason to send these to the monitors.
About the other stuff you are talking I'm not sure, I just use the sdk not the normal scope software. I always make manual dsp assignments so to know what to expect.

In any case, sometimes I use my ears with a well defined enough sample source via the samplefix tool from Red_Muze aka Assaf that you can find here, which is simple to use by sending the 'normal' channel into input 1, and the 'effected' or parallel version of that into input 2. This of course requires 2 instances if you are correcting a stereo pair. Sometimes I do as mentioned above, and measure the result by recording directly into the daw. Sometimes it might also make sense use that initial starting cycle, and an ending cycle, with a Ramp in between. Depends on what is being tested..Ramp can show different axes of phase relationship. Or even other test tones, of course.

I'm not sure what you are talking about here. There is no way for me during work to start counting samples and fixing phase. I did that just once then tested some times for consistency, test proved right. When I used an analog compressor for parallel compression I measured the round trip -it is 171 samples in my case. I don't do it any more, there is no benefit in analog compression in my work. For analog I just use my custom made analog filters and a distortion stomp box.

Care should be taken when doing look-ahead limiting, use dsp delay lines to compensate for the look-ahead time.

Also a final tip for the details lover. Have you heard anything unusual with all scope delay fx? They kind of suck isn't it? This is because the delay lines are splitted to the SDRAM or computed on the host RAM, making all feedback audio to be futher and further delayed inaccurately. No way to have a perfect sample accurate delay fx and you notice the ugly smearing at the repetitions with percussive sounds? This is nusty comb filtering and no it cannot be used as a phaser... In Xite there is enough memory on each DSP that a delay fx device can be made that is sample accurate. (using two DSP's for stereo ). Perhaps I'll upload it someday. It is perfect.


In general find the faster and the easiest way of working to get repetitive know-what-to-expect results.

[garyb]

yes, but the problem is how much latency between ADAT ports on two different pieces of hardware.

this is a ludicrous question in the hardware world. there are certainly musical forms where this might be an issue(latency between ADAT ports), but for most work, it is negligible. add a few other hardware devices and there will be very little that can be done about it, certainly nothing that would make even one penny less commercially. ALL music made before 2010 had this issue to some degree, older stuff more than newer stuff. yet, all the music that has really inspired both gear, apps, and music today had minor phase issues. its funny how the world's greatest recordings have bigger latency issues just from the studio wiring.

i know that working strictly inside the DAW will eliminate the chances of small latencies creating minor phase issues, but i have not heard any music that has been better just from that. it's just my opinion, but i don't think this is something to worry about until the level of complexity gets near the computer's upper limits.

i guess the real solution is don't use hardware. that stuff sounds awful. it's amazing that anyone would emulate it.



my last comment is that the other opinions in this thread are QUITE valid, i am just a simpleton, trying to keep things simple. YMMV.

[fra77x2]

Gary you should differentiate between analog and digital domain and when that stuff matters. If you process signals serially without doing parallel then there is a constant latency of the audio path (which is negligible with analog devices and cables anyway) that can be compensated by dragging the audio a bit back. No big deal. From the time of tape recorders that was feasible. When you do parallel, if you use analog devices then the processing (it becomes a signal there are no more "samples") and the comb filtering is attenuated or non existant. But when you work in digital domain that stuff is crucial if you want to listen to the real performance of the devices. Good sound was always produced by people that knew their tools and how to achieve their tasks. The "world's greatest recordings " of course do not have "latency issues". What do you mean? It's a different thing latency that can be compensated and digital phase issues that affects destructively the audio.

The answer to the OP

If i run a signal from a converter to a Scope Pro ADAT in and route it directly into the Scope ADAT Dest then into Xite ADAT in, will there be any significant (audible) latency?

is yes there is. But what you mean significant? Audible? Latency is not audible unless you measure the time you struck a key. Latency is identified in relation to something, press of a key, relation to other sound devices...

So there should be some minor latency, measurable and consistent, but it depends what you are doing with the ADAT signals that is going to affect how you treat it and if you should care about it.

For simpletons:
a. In analog domain the phase issues are of no concern. You can continue using your lovely hardware.
b. In digital domain. Phase issues are important. Try to learn this stuff it is really simple.

[garyb]

those issues were destructive back in the 1950's, 1960's, 1970's, 1980's and 1990's. people did what they could to minimize them. audio has not moved forward one iota since. crappy music is not better for being sample accurate, neither is good music worse for some minor variances.

i am NOT saying that these things are best ignored, but neither will i get overly dogmatic about it. sometimes the comb filtering is perfectly acceptable, sometimes it is not. that has little to do with the latency between ADAT ports. what is that acronym? KISS.

but what do i know? i work for some very successful artists and engineers, and have produced music that made the US charts, and have sold some of my own crap. i'm a practical guy. the theory is only important if it's in my way. as far as audio goes, digital or analog, it's the same.

i already acknowledged that these issues may be VERY important, depending on what one does. if it's fun to listen to, i'm not concerned with perfection. if it's not fun to listen to, then perfection surely did not help.

all i said was that it's perfectly fine to connect a card and an XITE via ADAT and then just not worry about latency. any audio issues will be apparent and can be dealt with as needed. for MOST music, it won't matter.

[fra77x2]

"audio has not moved forward one iota since"

Gary why are you insisting? They are not the same and please keep your ignorance to yourself. You can't understand the difference between latency and digital phase. We are trying to get better.
It is not a matter of seeking "perfection" or of being dogmatic or not, this not religion, they are facts concerning the way things work. Your reply drifts between "that could be ignored" and "VERY important" so choose. Exactly "depending on what one does". That is what we are trying to illustrate here: That depending what one does and the domain one works in, their influence can range from "could be ignored" to "VERY important". And we are trying to clarify this matter especcialy the "VERY important" part. It does not help to say that for "most music" it won't matter. The music or whatever is represented by such signals is unrelated. This is about signals. Signals behave differently in analog and digital domain because of the different nature of them. In analog they are electromagnetic and continuous but in digital are a series of numbers and discreet. So when you make computations with discrete samples you get different results than manipulating electromagnetic signals.

I stop here, I don't want to convince anyone just choose your way of working and suits you better. Perhaps the best sound engineers are completely ignorant and don't spend their time learning ugly "theory". You can always cross your fingers that your music is inside Gary's "MOST music" category and move on. If you hear something strange, who knows what it could be there are so many factors, it is all soooo confusing and you know... you can always buy some more gear until you find some "real" machines that will make you famous... In any case "HAVE FUN". Ha ha ha

[valis]

Gary's correct, before we created things entirely in the digital realm, phase was certainly an issue! Multiple microphones in the same room attempting to close-mic an instrument had TONS of bleed through compared to modern digital workflows. 20-25dB down in the mix was often a swimmy mess, and filters could be surgical in some ways but nothing near what we have now. In fact I stated that in my post above his--that I used to do this on my boards (and still do) and so the habit pre-exists Scope and even digital.

I also agree with his point that checking sample accuracy isn't a dogma, and take his postings being targeted at the 120 people he's communicated with behind the scenes that are relatively neophyte and just coming to grips with getting routing working and loading devices. Imagine the support emails he's thinking will result from a thread such as this

[fra77x2]

Valis latency is not a phase offset, because phase is related to a copy of a signal to itself or to an elementary waveform described as a mathematical equation. Latency is a delay of a signal. Two uncorrelated signals have no phase relationship to one another. With multiple mics there are phase issues but of a different nature because this is analog domain. Of course if you are addressing "neophytes" you can tell them that life is long and you will always learn but once in a while while there is a chance of knowing something it would be best to lower our supposed adequacy and hear some things. Phase is not something specific to scope but in scope it manifests in a unique way because of the automatic distribution of computation to the different dsp's which happens randomly between different project loading. People should know this so to make their lives and their careers more satisfying. For a contemporary sound engineer knowing this stuff is elementary.

'Imagine the support emails he's thinking will result from a thread such as this

I'm working for him :=)

Explaining this thing in its full glory is a very straightforward matter it can be covered in 5-10 minutes. Just make a youtube video with some explanation and perhaps pin it on the "scope creativity" or even better in place of the "security and privacy" thingy.

[valis]

You’re being pedantic perhaps?. Latency between correlated signals certainly will result in a phase offset. the first the example given was parallel processing—remember? As well as comparing a single cycle impulse offset in time in e DAW.

Phase angle φ = time delay Δ × frequency f × 360

This also applies to spatial effects, which appear to a Multi-mic setup as certain portions of the sound being time delayed between one microphone and another at a further or closer distance, which was mentioned as well. Hence Gary’s broad strokes reference to past productions over the decades.

Also you’re bringing things into play that have no bearing on this discussion, chill. The point was not to invite attacks, but rather we were all discussing different workflows and what works for us is perhaps particular to the sort of tasks that we use in producing our music, which branched off of the root question of this topic—how much latency does ADAT add? A few samples...

[fra77x2]

My friend when I post in this forum I am very careful because I know the story.

Let me clear a bit the mist.

You reply (before I make any posts) in this thread as

Still important to correct this offset (a few samples) if you're doing parallel processing.

GaryB reply:

only for some music.
with hardware and real patchbays and mixers, those kinds of offsets are normal and part of why things sound great, sometimes...

computer nerds are funny sometimes.

By my understanding he hasn't even understood your reply. You mention parallel processing and he replies: only for some music!
The "phase accurate" music. All other music is normal. Perfect "phase accurate" music is made by nerds and you know we don't spot any difference and we also don't like it....

He also calls you a computer nerd in a "friendly" response that you know a lot of "difficult stuff". You reply by admitting the
"friendly" call. -> Yes, I am indeed a computer nerd

Then I post

Some tips not related completely to the thread but about the "offsets"

I'm quite clear that I'm talking to you Valis. You mentioned parallel processing and the "offsets" I'm giving my advice how to do that stuff without a problem, without testing it.
Also I'm not trying to confuse anyone, I write:

In digital domain sample accuracy is a must if you do parallel stuff.

So if anyone neophyte reading this can ask himself "do I do parallel stuff"? What is this? I don't do it so it does non concerns me.
Does the ADAT introduces latency? A neophyte should have a vague idea about what latency is especially when the neophyte is over 65.

You then reply with a long post.

I reply to you.

Then Gary adds:

yes, but the problem is how much latency between ADAT ports on two different pieces of hardware.

i know that working strictly inside the DAW will eliminate the chances of small latencies creating minor phase issues, but i have not heard any music that has been better just from that. it's just my opinion, but i don't think this is something to worry about until the level of complexity gets near the computer's upper limits.

"ALL music made before 2010 had this issue to some degree, older stuff more than newer stuff. yet, all the music that has really inspired both gear, apps, and music today had minor phase issues."

This reply is problematic. He does not address the question that the OP asked, because sending signals to ADAT does not create phase issues per se. It can create phase issues in the context you Valis and I we were talking about i.e. In the specific case when doing parallel processing.

In general, sending signals to ADAT only introduces some minor latency that everybody can live with.

I then reply being very careful to address the specific problem and what I thought Gary was not taking under consideration i.e. when are phase issues important, under what circumstances and during what procedures obviously in the context your reply and my following replies where talking about.

Gary then replies:
those issues were destructive back in the 1950's, 1960's, 1970's, 1980's and 1990's. people did what they could to minimize them. audio has not moved forward one iota since. crappy music is not better for being sample accurate, neither is good music worse for some minor variances.

Stuck in his ideas. Hasn't heard anything, he starts talking about crappy music and his bizzare idea of non evolution of audio.
sometimes the comb filtering is perfectly acceptable
Yeah yeah.

You then reply in support of Gary, obviously because you don't like me telling you how to work.
And you know it was expected.

So I'm not pedantic I try to be helpful and of course I get tired when reading ill-digested knowledge presented with the pose of authority.