Questions & Answers

closed [Completed in 3.5.1] True low latency monitoring for virtual instruments (also after 3.5)

+187 votes
asked Dec 16, 2016 in Completed Feature Requests by niles (52,500 points)
closed Jul 2, 2017 by niles

This feature request was implemented in version 3.5.1 so this request can be closed!

A big thank you to PreSonus Software for implementing this request and of course a big thank you to all the people who supported this request.

Very much appreciated!

A brief note
It seems PreSonus altered Studio One's safety buffer This results in the lowest possible ASIO latency because there's no additional buffer between the application and the ASIO buffers (as requested).

When using a buffer size of 128 samples and a sample rate of 44.1kHz, this comes down to an average of 6.6 ms. That's a 30% lower latency than before. With low latency monitoring enabled this will result in a virtual (reference material is delayed) low latency of a small 4 ms.

As you can see in the image above there's a trade off by the removal of the extra safety buffer. The real time audio (so not what is playing back, but what you hear while playing) has a deviation of ~2.2 ms. In this case the latency sometimes is 5.6 ms while the other moment the latency is 7.8 ms. This is an inevitable part of the ASIO technology itself due to buffer changes on real time input. 2 ms however is imperceptible. Fortunately PreSonus added a safety buffer at higher buffer sizes (above 256) because the deviations there can become noticeable then since the buffer cycles become larger.


Read below why this request is still relevant after the introduction of Low Latency Monitoring for instruments in Studio One 3.5 (jump to post)

I would like to request an overall lower real time audio latency when playing virtual instruments in Studio One.

When I play virtual instruments in real time with an ASIO buffer size of 128 samples at 44.1kHz it should take an average time of approximately 6 ms before I hear the sound after a MIDI trigger is received by the host  (ASIO I/O buffers / Sample rate = 128 + 128 / 44.1 = 5.8 ms). However in Studio One it takes an average of 9.7 ms before I hear the actual sound in real time after the MIDI trigger is received. Almost 10 ms really is very long for an ASIO buffer size of 128 samples and a sample rate of 44100hz. I've ran some latency tests across several hosts and Studio One was almost twice as slow as the most responsive host.

MIDI trigger receive (MIDI In) --> Bitwig + VSTi --> Sound (RT VSTi Audio) = 4.7 ms (average)
MIDI trigger receive (MIDI In) --> Cubase + VSTi --> Sound (RT VSTi Audio) = 5.5 ms (average)
MIDI trigger receive (MIDI In) --> Digital Performer + VSTi --> Sound (RT VSTi Audio) = 6.5 ms (average)
MIDI trigger receive (MIDI In) --> Reaper + VSTi --> Sound (RT VSTi Audio) = 7.6 ms (average)
MIDI trigger receive (MIDI In) --> Studio One + VSTi --> Sound (RT VSTi Audio) = 9.7 ms (ave

Notice how consistent Studio One's MIDI and Audio (and their relation) are, but also notice at what huge latency trade-off compared to Cubase (without ASIO latency compensation, which would improve it even further). Bitwig goes even lower but unfortunately the notes in Bitwig aren't placed where they are actually played, so there's a compensation made to the MIDI events afterwards.

Additionally I think most of us are familiar with the phenomenon notes are recorded ahead of time in Studio One. This is because the musical data is extremely accurate. So when you hit a key the musical data (MIDI) is recorded instantly. However the actual sound will take approximately 10 ms with an ASIO buffer size of 128 at a sample rate of 44.1kHz. So in order to get the sound on the right spot when playing in real time (without IQ), you have to play 10 ms earlier. Causing the note to be registered 10 ms earlier. However on playback that 10 ms is compensated and so what you recorded, sound different when you play it back. This is why the lowest possible latency is important, so the human compensation will be minimal.

closed with the note: Feature was implemented in Studio One version 3.5.1

10 Answers

+5 votes
answered Dec 20, 2016 by AlexTinsley (775,480 points)

Thank you for the feature request. 

If anyone else agrees or disagrees, then please vote it up, or down. 

To vote:

In agreement click on the little blue triangle pointing up.

In disagreement click on the little blue triangle pointing down.

The developers pay close attention to those that are voted on the most. 

You are allowed one vote. 

Just viewing and agreeing but not clicking on the vote does not help the issue. 

Please click on one or the other.

0 votes
answered Feb 19, 2017 by henricschleiner (150 points)
Is the problem solved?
My latency is at 11.5ms under 48kHz, 256bit, Studio 192 and windows 10.

That's a real reason to return the device.
0 votes
answered Feb 23, 2017 by niles (52,500 points)
edited Feb 23, 2017 by niles

@ henricschleiner answer: I'm not sure what latency you are referring to. Concerning the latency in this request: No, that's not solved. 

Regarding the latency you are mentioning, it's hard to tell without knowing exactly what you are measuring. For example: An audio round trip latency of 11.5 ms at 48kHz and an ASIO buffer size of 256 isn't bad. However when it  costs a VST Instrument 11.5 ms to generate its sound after the MIDI trigger is received in real time (what this request is about), 11.5 is way too much. The latter won't be solved by using a different ASIO device.

–1 vote
answered Mar 27, 2017 by Jemusic (350 points)
It depends. I have recently got an iMac and I am running a Focusrite thunderbolt interface. My round trip lately is about 2 mS all up. Yes that is right. For me this is the fastest response I have ever experienced. I can run 32 samples all day long no issues.
0 votes
answered Mar 28, 2017 by niles (52,500 points)
edited Mar 28, 2017 by niles

Jemusic answer: Given the fact you speak about "round trip latency" clearly shows you don't have a clue what this request is about. Calling random numbers without telling/showing the exact context only tells me you are happy with you setup. That's good for you, but subjective and irrelevant to me (and this request).

0 votes
answered Apr 27, 2017 by HitzHits (670 points)
Logic Pro X has a Low Latency mode (one button) that you can click to play any VST instruments. Such a mode would be amazing in S1.
0 votes
answered Apr 29, 2017 by niles (52,500 points)

answered by HitzHits: Yes, the Low Latency mode is a nice feature. Cubase has it too and it's called Constrain delay compensation thereHowever Low Latency mode & Constrain delay compensation are different from what I request here. What Low latency mode & Constrain delay compensation are doing is temporarily disabling plugins that exceed a certain latency threshold. This way the overall project latency can be temporarily brought down to the point where you started the project (without latency introduced by plugins). 

This request is about lowering the initial real time latency (so without latency introduced by plugins) when monitoring (VST) instruments.

+1 vote
answered Apr 30, 2017 by musicmould (1,830 points)
edited Apr 30, 2017 by musicmould

A low latency mode à la Logic Pro X would be awesome. Really missing that since I left Logic. frown

When you have a really big production and need to add a virtual instrument the latency can be crazy.

I wish Presonus would "think outside the box" and find some kind of even better solution than Logics.

0 votes
answered Apr 30, 2017 by niles (52,500 points)

answer by musicmouldAgree, features like Logic's Low Latency Mode or Cubase's Constrain PDC are good solution to get the latency as low as possible. BUT it all starts with initial latency. That one should be as low as possible from the start.

Currently Studio One needs 9 ms to process 256 samples (2*128) at a rate of 44100hz, while other hosts do it in considerably less time (almost twice as fast). To keep latency as low as technically possible, it should start at the core (application > ASIO driver > hardware). All alternatives to (temporarily) bring down latency like the aforementioned methods or improved stability at small ASIO buffer sizes like Reapers Anticipative FX Processing, Cubase's ASIO guard or Ableton's Reduced Latency when Monitoring are all icing on the cake but don't lower the initial latency when playing (VST) instruments in real time.

+2 votes
answered May 25, 2017 by niles (52,500 points)
edited Jul 2, 2017 by niles

With 3.5 PreSonus did a great job finding an alternative monitoring solution for virtual instruments. When Low Latency Monitoring for Instruments is enabled, the non monitored tracks are delayed and therefor the user will overcompensate less for the actual latency (comparable to Ableton's Reduced Latency when Monitoring). With a buffer size of 128 samples and a sample rate of 44.1kHz the average latency between the reference material and the monitored instrument is 7.6 ms (the same as Reaper in the test above).

U̶n̶f̶o̶r̶t̶u̶n̶a̶t̶e̶l̶y̶ ̶t̶h̶e̶ ̶a̶c̶t̶u̶a̶l̶ ̶l̶a̶t̶e̶n̶c̶y̶ ̶d̶i̶d̶ ̶n̶o̶ ̶d̶e̶c̶r̶e̶a̶s̶e̶,̶ ̶o̶n̶ ̶t̶h̶e̶ ̶c̶o̶n̶t̶r̶a̶r̶y̶ ̶i̶t̶ ̶i̶n̶c̶r̶e̶a̶s̶e̶d̶ ̶f̶r̶o̶m̶ ̶9̶ ̶m̶s̶ ̶t̶o̶ ̶a̶ ̶s̶t̶a̶g̶g̶e̶r̶i̶n̶g̶ ̶1̶5̶ ̶m̶s̶ ̶w̶i̶t̶h̶ ̶a̶n̶ ̶A̶S̶I̶O̶ ̶b̶u̶f̶f̶e̶r̶ ̶s̶i̶z̶e̶ ̶o̶f̶ ̶1̶2̶8̶ ̶s̶a̶m̶p̶l̶e̶s̶ ̶a̶t̶ ̶a̶ ̶s̶a̶m̶p̶l̶e̶ ̶r̶a̶t̶e̶ ̶o̶f̶ ̶4̶4̶.̶1̶k̶H̶z̶ ̶w̶h̶e̶n̶ ̶w̶o̶r̶k̶i̶n̶g̶ ̶w̶i̶t̶h̶ ̶t̶h̶e̶ ̶t̶r̶a̶d̶i̶t̶i̶o̶n̶a̶l̶ ̶s̶e̶t̶t̶i̶n̶g̶s̶ ̶(̶D̶r̶o̶p̶o̶u̶t̶ ̶p̶r̶o̶t̶e̶c̶t̶i̶o̶n̶ ̶s̶e̶t̶ ̶t̶o̶ ̶M̶i̶n̶i̶m̶u̶m̶)̶.̶ ̶S̶o̶ ̶u̶n̶f̶o̶r̶t̶u̶n̶a̶t̶e̶l̶y̶ ̶t̶h̶i̶s̶ ̶f̶e̶a̶t̶u̶r̶e̶ ̶r̶e̶q̶u̶e̶s̶t̶ ̶i̶s̶ ̶s̶t̶i̶l̶l̶ ̶r̶e̶l̶e̶v̶a̶n̶t̶ ̶f̶o̶r̶ ̶t̶h̶o̶s̶e̶ ̶w̶h̶o̶ ̶d̶o̶n̶'̶t̶ ̶n̶e̶c̶e̶s̶s̶a̶r̶i̶l̶y̶ ̶n̶e̶e̶d̶/̶w̶a̶n̶t̶/̶c̶a̶n̶ ̶u̶s̶e̶ ̶t̶h̶e̶ ̶v̶i̶r̶t̶u̶a̶l̶ ̶l̶o̶w̶ ̶l̶a̶t̶e̶n̶c̶y̶ ̶s̶e̶t̶t̶i̶n̶g̶ ̶i̶n̶t̶r̶o̶d̶u̶c̶e̶d̶ ̶i̶n̶ ̶3̶.̶5̶.̶

So why would someone not want to use the 3.5 virtual Low Latency Monitoring for instruments?

  1. The sound of virtual instruments will temporarily stop each time you monitor a different track. Also the first note(s) won't play the first time after switching the monitoring state.
  2. The Instrument's CPU's strain is doubled when monitoring with LLM enabled.
  3. Instruments and inserts with (synced) internal arps, lfo's, sequencers, step editors, delays etc. will be temporarily out of sync when monitoring.
  4. Inserts with a latency > 3ms in the audio path of the monitored instrument, won't process the sound of the monitored instrument.
  5. Automation of faders, panners and parameters of inserts on buses within the low latency path are not being processed on playback.
  6. Automation in general is responding slower than when dropout protection is set to Minimum.
  7. Inserts on a bus that receives audio from the monitored instruments are not able to show metering, tuning, analysis etc. for the monitored instrument (so beware with bus processing and relying on meters).
  8. It's not possible to record audio directly to a stereo audio track with the Instrument as input source when the Instrument is monitored.
  9. Latency compensation between the high latency path (processing block size) and low latency path (device block size) is not sample accurate, so layering instruments will give unpredictable results after the monitoring state is switched.
  10. The CPU hit can be extreme when monitoring the first channel of a multi channel instrument containing effects on the different channels.
  11. Instruments with MIDI output can play irregular due to the larger processing buffer when not constantly kept in the low latency monitoring path.