Thanks so much for these numbers, niles (legend). Really appreciate it. A very interesting read.

Those Cubase numbers are impressive. Gotta love those RME drivers.

Did you happen to do any tests at 96 kHz? Specifically ASIO 32 with LLM at 96 kHz and ASIO 64 without LLM at 96 kHz. Those would be interesting, for reference.

Back on topic please.

jpettit wroteBack on topic please.

We're not? (Honest question.)

For some reason people are not factoring in my instrument monitoring results. At 32 samples I can get 4.5 mS latency (RME) and at 16 samples 2.9 mS. But this is with the thunderbolt Focusrite interface on a Mac though.

I have discovered that an RME Fireface 800 interface shows up the 16 sample buffer setting. I will do some tests on that to see.

I get these results with LLM not engaged though. LLM for me makes things worse than these figures. For best results I have to set DP for minimum and setting the buffer the usual way. So for me 3.5 is no worse than before and in fact with the 16 sample buffer setting now it is actually better. 2.95 mS is damn fast for instrument performance.

These figures for me are all at 44.1K sampling rate as well.

Skaperverket wrote

jpettit wroteBack on topic please.

We're not? (Honest question.)

The topic is DP and NLLM new in 3.5.
Benchmarking particular vendors ASIO performance should be another thread.
Thanks

Jemusic, those numbers are quite impressive as well. And they differ quite a lot from niles' findings, even though his computer's specs are supposed to be markedly better. Looking forward to seeing your FF800 numbers as well. Thanks.

I understand, jpettit. You guys are the bosses. I hope everyone is happy with the new engine in the end. A lot of this is promising and I like that these things are being addressed.

If you create a thread for latency numbers, niles (or Jemusic), I would follow it with great interest. Thank you.

Why is this only outputting to mono audio tracks when in Low latency mode?

viewtopic.php?f=213&t=25869

mikemanthei wroteI'm getting noises when using fader automation on the master fader... The noise is essentially the audio at 0 db. (no attenuation) for a very short amount of time. The shortness of the error makes it sound a bit like a "pop".

Update:
This issue seems to be more prevalent with songs that were created with 3.4. So maybe it's a conversion issue?

I was able to replicate this under many different scenarios. Even after trimming all 3rd party plugins out of the song, and removing many Presonus plugins as well, the issue persisted. And I've only heard it on songs that started in S1 3.4. and converted to 3.5.

After discussing this with Presonus Technical Support and sending them a stripped down song as an example, they were able to reproduce in their lab... so hopefully a fix will make it into the next release.

If you haven't seen the issue, good for you. But be cautious of your mixes until this is resolved. the "random" noises survive both playback and the mixdown stereo master...and the noise isn't always in the same place in the mixdown file as it was in the playback.....so you might inadvertently have noises in your masters. The noise can be masked by loud mixes, and I only discovered the problem because it stood out on a long fade-out. But it can exist in louder sections of the audio as well.

mikemanthei wrote

mikemanthei wroteI'm getting noises when using fader automation on the master fader... The noise is essentially the audio at 0 db. (no attenuation) for a very short amount of time. The shortness of the error makes it sound a bit like a "pop".

Update:
This issue seems to be more prevalent with songs that were created with 3.4. So maybe it's a conversion issue?

I was able to replicate this under many different scenarios. Even after trimming all 3rd party plugins out of the song, and removing many Presonus plugins as well, the issue persisted. And I've only heard it on songs that started in S1 3.4. and converted to 3.5.

After discussing this with Presonus Technical Support and sending them a stripped down song as an example, they were able to reproduce in their lab... so hopefully a fix will make it into the next release.

If you haven't seen the issue, good for you. But be cautious of your mixes until this is resolved. the "random" noises survive both playback and the mixdown stereo master...and the noise isn't always in the same place in the mixdown file as it was in the playback.....so you might inadvertently have noises in your masters. The noise can be masked by loud mixes, and I only discovered the problem because it stood out on a long fade-out. But it can exist in louder sections of the audio as well.

This has been addressed.

Skaperverket wroteThose Cubase numbers are impressive. Gotta love those RME drivers.

3.5.1 finally brings us true low latency too.
As you know...

jpettit wroteBenchmarking particular vendors ASIO performance should be another thread.

...so I'll post a comparison somewhere else.

Sorry Niles this thread got morphef around a bit so posted here is fine or elsewhere if you want.

jpettit wroteSorry Niles this thread got morphef around a bit so posted here is fine or elsewhere if you want.

Let's finish it here then for completeness sake

Studio One 3.5.1
ASIO | Mon | LLM

32 | 4 ms | 5 ms
64 | 4 ms | 2 ms
128 | 6 ms | 4 ms
256 | 15 ms | 10 ms
512 | 27 ms | 15 ms
1024 | 50 ms | 27 ms

The coolest part (you can't see that from these figures) is: The higher the latency is, the more consistent it becomes. That's not something ASIO technology itself does. Normally high ASIO latency (large buffers) will cause bigger fluctuations in timing because the large slow buffers aren't always on the right spot when they need to process real time data. Try to run a host like Cubase at 1024 samples and you'll notice the real time generated sound is far from consistent.

The PreSonus developers however seem to have found a way to create some sort of small safety buffer that increases when the ASIO buffer size increases above 256 samples. So with small ASIO buffers the safety buffer is marginal and thus the audio has a slight deviations due to the ASIO buffer cycles. But because the latency is very small and the buffers are quick the deviations are negligible (0.8 to 2 ms). But what is interesting is that the deviations above an ASIO buffer size of 256 samples becomes only a few samples. This is nullifying the jitter caused by the ASIO buffer cycles in real time. Which pretty cool because that's where deviations can really become in your way since the larger buffers are slower.

Nice one

This is wonderful, wonderful news. Thank you, niles. And thank you, Presonus.