Skip to main content

Let me explain...
I decided to check how the latency was with the fireface 800 I just got.
I'm set at 512 and decide to do a round trip through my 2 LA-610.
The chain was, line out of the RME, line in of the LAs, AD96 and S/PDIF to the RME.
I took a drum sample that I played and recorded the re-amp version.
I measure the time differencial with Auto align from sound radix and zoomed in the wave displays because I couldn't believe it. Zero sample of difference.

This made me think.. is it possible that Sonar uses the buffer only when it needs it ?
Which they had a buffer meter..
Thing is. . . when using a VSTi controled by my electronic drum on a clean project (no other vst) I get no latency. If I do the same on a busy mix.. I get a slight delay.

How does that work ?
I get the feeling it wasn't like that with older versions... But then, I wasn't using the RME and wasn't running it on the same OS either..

Topic Tags

Comments

Boswell Sun, 07/12/2015 - 15:52

Buffers are always needed, but quality DAWS have latency compensation - they time-advance the replay so that capture of the same signal or signals derived from it appears with no apparent latency. Buffer size is automatically taken into account in this process.

It's very different when you have an analog input, process the input and then re-output the result. There can be no time advance in this case, and it relies on the amount of CPU power available to get the process done. Stack several of these tasks up and you start hearing the delays.

pcrecord Sun, 07/12/2015 - 17:12

Ok, I went back to it with an amp simulator.
I have 96, 128, 256, 512, 1024, 2048 samples. Thing is, on an empty project, I get no latency at 512 and a very small one at 2048. On a full blown mixed project, I get a slight delay at 512, I'm guessing about 30 to 60 ms. This happens on idle and when playing the song.
I can't believe I'm not more aware of how this work. It seems Sonar is producing latency only when a lot of stuff is loaded regardless of the buffer settings which I tought were directly related.. lol !!
Or is it a driver thing ??

Boswell Mon, 07/13/2015 - 02:41

It's something that differs greatly between DAWs, but is not particularly a driver thing. However, the idea underpinning latency compensation is that a DAW can time-advance any tracks that are being replayed from disc to compensate not only for the inherent delays through code and buffers but also for the known throughput times of any plug-ins on each track.

Even sophisticated DAWs cannot predict the future (though I have heard some people say that the next version of PT will have this feature), so data that comes from the outside world in the form of an input channel cannot have this latency compensation applied, at least, not in the same way. The best the DAW can do is to throw computing power at the processing needed, so a suitably-written plug-in can split its processing around all the available CPU cores to reduce the overall throughput time. You can see that it would not take many concurrently executing plug-ins or other tasks to reduce this to sharing a single core, and hence start to introduce audible delays.

pcrecord Mon, 07/13/2015 - 03:00

If I follow you, the delay I get on a fully mixed project would be caused by Sonar being prepared to play and process the song. In other word, the this would be the delay needed to compute everything without dropouts.
On that project I get a delay between the notes played on the guitar and the sound of the amp simulator I send it to. And on empty projects I get no delay.
What about the buffer interaction then ? The size of the buffer would only serve to compute more things at the time and avoid dropouts?
Sorry if I'm so lost about that !! In my mind, if I didn't want delays I'd need to lower the buffer's size.. but now I realise it isn't required anymore...

DM60 Mon, 07/13/2015 - 03:34

I would suspect that the delay is as much to do with processing the effects in real time as anything else. Even as fast as our computers are getting, there is still threads and queues, etc that have to be processed. One feature I think that gets overlooked in many DAWs is the freeze track feature, using this would probably reduce the latency issue on a large track project.

At some point, the computer CPU will have wait times for processing.

DonnyThompson Mon, 07/13/2015 - 03:58

DM60, post: 430596, member: 49090 wrote: I would suspect that the delay is as much to do with processing the effects in real time as anything else. Even as fast as our computers are getting, there is still threads and queues, etc that have to be processed. One feature I think that gets overlooked in many DAWs is the freeze track feature, using this would probably reduce the latency issue on a large track project.

At some point, the computer CPU will have wait times for processing.

pcrecord, post: 430597, member: 46460 wrote: I use the freeze track all the time, specially for Vsti.
I'm just surprise that the latency is not so dependant of the buffer anymore..

I also use Samp's Freeze function quite a bit ... like Marco, mainly for VSTi's, but certainly not limited to just those. I've currently got 16 gig of RAM loaded in my production PC, and most of the time, I don't get so much as a hiccup.

But, if I'm doing a project that's more dense, or where many different VSTi's are being use ( as with Superior Drummer, where I assign each drum/cymbal to its own discreet/separate Superior host ) then there are those occasionally scenarios where even 16 gig can max-out and start to cramp up on me, even at the highest buffer settings ( 2048).

DM60 Mon, 07/13/2015 - 04:24

pcrecord, post: 430597, member: 46460 wrote: I use the freeze track all the time, specially for Vsti. ;)

I'm just surprise that the latency is not so dependant of the buffer anymore..

Probably just more powerful CPUs and faster HDs. SATA drives have really improved the I/O performance, add to that an SSD, the increase in data I/O performance has increased significantly.

When doing an OS class, one of the major areas of focus of design was I/O schemes since that was the slowest part of computing. Seems to being reduced more and more with more RAM, faster I/O connections and faster responding (less seek time) HDs.

pcrecord Mon, 07/13/2015 - 13:00

I'm in love with the stability of the drivers and Totalmix is fantastic !!
I haven't really used the onboard preamps yet but I got not glitch or sync problems with ADAT transfer. (I had some once in a while with the Focusrite)
Even if it's an old build that they sold over many years before today, I'd buy another one any time !!