I wanted to ensure that VST Connect PRO is providing sample accurate sync of the audio coming back from Performer into N10
So, I tested sending an Audio recording of a click track fom N10, via VST Connect Pro, to VST Connect Performer on a LAN connected MacBook Air and looped the output of the soundcard on the MacBook Air running VST Connect Performer back to an input of that same soundcard, in order to send it back to Performer Rec track in N10.
With the Buffer Size on VST Connect Performer set all the way down to 64, there is a latency of approximately 452 samples (around 9ms). If I increase the buffer size, the latency in the recording becomes even worse. I can never get it below 634 samples. Shouldn’t this recording line up to exactly where the source audio is in the timeline? I’ve tried adjusting the Remote Delay Seconds but the results were the same
Any help would, of course, be greatly appreciated
I’m running 4.0.44.360 on both machines.
Here’s a screenshot of one click that I recorded in N10. the “CLICK” lane shows the audio click happening at 30072 samples and the “Performer Rec” lane shows the looped through audio recording at 30436
This is weird, we had a similar complaint from Q&A and fixed it. VST Connect is sample accurate down to 1 sample.
However testing it again now, there appears to be a problem, will report back, thanks for letting us know. What Nuendo version are you using exactly?
if you are looping back the output of a soundcard back to it’s input aren’t you always going to see a delay that is based on the ASIO buffer size - and the latency from the D/A and A/D convertors. Nuendo/Cubase can to a certain extent allow for this as it knows the ASIO buffer size (approximately) but it doesn’t know the entire delay in the chain ?
Try the same loopback test in nuendo/cubase itself and cut VST connect out of the equation - is it in sample accurate sync ? How can it be as Nuendo can’t know the EXACT delay from your O/I and I/O chain.
I’m not saying there isn’t a problem here (!) and I’m not sure how VST connect allows for the ASIO buffer (approximately) and if that’s the part that’s broken…still not sure how anything can be guaranteed “sample accurate”
The only reason I did this test is because while playing back a percussion part I recorded, my playing just seemed a “bit” off. I’ve been playing for over 30 years and, while I’m not claiming to be especially sensitive to single digit ms differences in time, 9ms was enough for me to know that it wasn’t as in the pocket as when I record locally.
If the VST Connect Performer Buffer Size was set higher than 64, the recordings of my playing were even further off. So, that isn’t working as expected, I think.
Here are the results of that test, using only Nuendo and no VST Connect…
Nuendo does indeed know the I/O latency of my RME Multiface soundcard, down to the thousandth of a millisecond. With the buffer set at 4096, I played a single sample impulse out of a single output and physically patched that output to an input of the same soundcard. I recorded this looped through impulse onto different tracks, each using a different buffer setting, all the way down to 32. Every single recording was placed exactly in line with the original source impulse sample. This was the expected behavior.
I can do the test with VST Connect and change the buffer size on the VST Performer side and the impulse will be further and further off as I increase the buffer size.
interesting result - and yes that RME sound card seems to report back very accurately. I’m using an RME raydat - which also gives an ‘accuracy’ to 1/1000th of a millisecond …BUT it’s not correct for my setup. The raydat card has no a/d convertors and so I have some external A/D and D/A and these add latency that cannot be reported by the RME driver.
This false sense of accuracy it true of the way many audio cards report back their latency … they aren’t guaranteed figures and vary from manufacturer to manufacturer - RME are one of the good ones.
You’ll notice something odd about your results/picture too…looks like your Multiface can see into the future - so something isn’t quite in sync there. There is some ‘ringing’ around the impulse after it passes through the loopback, which is to be expected…BUT why does the ringing in the recorded tracks happen BEFORE the impulse…it’s ‘anticipated’ it or it has seen into the future ? It starts ‘ringing’ 10 samples too early ?
Again - I’m not saying that there isn’t a problem with the sync with VST connect
Yeah, I thought that was strange too. Regardless of time-travel, the peak of the pulse at exactly the same sample point in the timeline where the peak in the original impulse is
Here’s a screenshot of a further test I did in the same N10 session but now adding VST Connect PRO into the equation, looping the input and output of the soundcard at the VST Performer end and changing the Buffer Size on the VST Performer end and recording the result in N10.
I’m scratching my head about this the entire day yesterday and further on.
We have an internal test procedure where the Performer “simply” bounces incoming buffered and timestamped audio unmodified. That test succeeds with sample accuracy.
Audio devices do report their latency. So we adjust the timestamps accordingly; it takes output latency samples until the signal arrives at the speaker/headphones, you perform to that, and it takes input latency samples for the input signal to be available at that point in time. There was a bug in that, and we fixed it, yet I also still get strange results.
A/D and D/A latencies may indeed cause shift of a few ms if the audio driver doesn’t take those into account. However that would be a constant offset that would not change with buffersize.
Your numbers indicate that that somehow doesn’t work. If you subtract two times the buffersize (which is usually what i/o latency is) in each case, you’ll end up with a pretty consistent shift of around 224 samples. This makes me wonder if you are indeed using version 4.0.44, could you pls double-check?
But then I can somehow reproduce it, need to check other audio interfaces. So, hold the line, we’ll figure it out
Tried again with an iConnect ASIO interface (Performer side, it’s the one that matters). Approx. 160 samples shift, but most of all: consistent with whatever buffer settings.
Prior test was with ASIO4All and local Broadcom audio where I also experienced a shift depending on buffer size.
I take from that that we’re good and it works like intented. We must rely on the audio device reporting i/o latency correctly, and as long as the bounce test is ok there is not much more we can do but compensate for reported i/o latency.
What does concern me is that RME are known to be very precise, will try to get hold of more interfaces to check against. However, the Performer system is what matters here, and I take that your loopback test was with its internal audio?
One remark: do not send a “one sample click” unless you use lossless transmission. The audio compression algorithm (codec) doesn’t like it that much Better to use a distinct pattern like a sinewave, or actual stereo music, by zooming out to the sample you can spot it quite well even with compressed audio.
Thanks for testing!
