Any improvement on latency? It all depends on jack2 implementation? Fractal devices add just 2ms of latency. I suspect 8ms could be not that good.
Checkout this, is a low latency OS designed for audio applications. Looks amazing. maybe you could grab some concepts and throw it into MOD architecture.
1 Like
The Elk is indeed a nice product, but it is very different than what MOD offers. The main problem with the latency is to be able to reduce the block length or the amount of periods per buffer in JACK. For that, Linux and the CODECs need to cope and it requires a great deal of tweaking.
The closest you can get to a low latency MOD environment now is its port to the RPi: MODEP in PatchboxOS: https://blokas.io/patchbox-os/ . Here you can easily get latency below 5ms.
Hopefully weāll be able to get similar values with the upcoming MOD Dwarf.
1 Like
Are you talking about block latency, or actual physical latency?
For latencies below 10ms, it becomes less and less viable to do so, and simply not worth it.
If playing with speakers/monitors, just the time it takes to reach your ears already gives you some latency 
I would even dare say that any latency below 6ms is non-noticeable by our ears.
I might be wrong here, but from what I understood of the ELK project, they separate the DSP from the main system. The DSP runs at very low latency, but it is also very limited.
For my understanding and leaving time and money aside: Wouldnāt every latency optimization help to optimize responsiveness when the system is under load?
8ms is definitely noticeable. Moreover if a wireless signal transmitter is used for in ear monitoring, you should add 3ms at least and if you add another wireless transmitter between instrument and MOD add 3 more milliseconds. I think overall MOD latency should be lowered down to 3-4 ms at max. I see latency on Windows is less than 3ms at 128 samples with ASIO drivers.
1 Like
But this is the block latency, not the actual physical latency. The distinction is quite important.
The block latency for MOD units is 2.6ms, because it runs at 48kHz rate with 128 buffer size.
8ms is the full in to out latency on a Duo.
And these values were set initially for the Duo, as it just cannot handle 64 frames properly.
We did not do many tests regarding reducing this on other models yet.
and yes, 8ms can be noticeable, specially for headphones.
there is a point where reducing the latency has diminishing returns (lots of CPU needed just for a few sub-ms less latency), but reducing 8ms to perhaps 6ms could still be worth it perhaps.
might be a good questions to users actually - is reducing latency at the cost of performance worth it? and how far?
1 Like
We should clarify first what performance means.
I meant complete system latency. With MODEP, they launch jack on sync mode (-S), which makes the round-trip latency at about 5.33ms for 128 samples per block @48kHz. Besides, there you can set the block length to 64 to further reduce it.
I find this sentence a bit misleading. Although 128 / 48k is indeed equal to ~2.6ms, we have 3 times that in the jack configuration.
8ms is definitely noticeable and one have to keep in mind that it comes on top of everything else (WiFi system, speaker to ear distance, etcā¦). So much so that it was the reason why I did the measurements in the first place.
This is a fair point, though Iād say especially for the MOD Duo. For the MOD X and the Dwarf, the CPU performance is much improved. One solution could be to leave it up to the user to select the block length, as already possible with MODEP (down to 64) and with MOD, though only between 128 and 256. One major improvement would be to be able to configure jackd on sync mode, thus going down to ~5.33ms. Not sure how much easier or harder it is than finding a way to set the block length to 64ā¦
2 Likes
Iām wondering where is the bottleneck, HW side or SW side?
My use-case is using the Duo X as a send-effect in my synth setup. When I apply the effects to something time crucial like drums (and this is one of the main reasons I bought it), each millisecond delay is more likely to be audible.
At least with MODEP on the RasPi 4 Iām only using ~30% of the CPU and Iām already happy with my rather wasteful designed board. Using up to 50% CPU (to leave 20% spare, dunno if this makes sense) to reduce the latency further sounds like a great idea to me.
1 Like
Alright, I can do some tests to see if 64 frames is feasible with the Duo X.
It needs to be 64 or 128, a power of 2, because a few plugins that do FFT require it.
At least disabling the JACK2 async mode will already help
3 Likes
i like the idea of going down some msā¦ would love to try 64 framesā¦ using the modx i have plenty power left most of the timesā¦
So a few tests with the Duo X (initial model), using jack_iodelay tool to measure physical out-to-in latency.
This measures full input and output latency combined.
Current defaults (128 frames, 2 periods per buffer, async mode):
406.723 frames 8.473 ms total roundtrip latency
extra loopback latency: 22 frames
Safer sync mode (128 frames, 3 periods per buffer, sync mode):
405.718 frames 8.452 ms total roundtrip latency
extra loopback latency: 21 frames
Defaults with sync mode (128 frames, 2 periods per buffer, sync mode):
277.724 frames 5.786 ms total roundtrip latency
extra loopback latency: 21 frames
Safer 64 frames mode (64 frames, 3 periods per buffer, async mode)
277.723 frames 5.786 ms total roundtrip latency
extra loopback latency: 21 frames
Safer 64 frames sync mode (64 frames, 3 periods per buffer, sync mode)
214.723 frames 4.473 ms total roundtrip latency
extra loopback latency: 22 frames
Defaults with 64 frames mode (64 frames, 2 periods per buffer, async mode)
failed, cannot run
Defaults with 64 frames sync mode (64 frames, 2 periods per buffer, sync mode)
failed, cannot run
So, contrary to the Duo, the Duo X is able to run at 64 frames quite okay (if 3 periods per buffer is also enabled).
Doing so reduces the latency by around 2.7ms.
Instead of reducing buffer size, using sync mode can be done to reduce latency without impacting CPU.
Doing so reduces the latency by around 0.02ms for 3 periods per buffer, or 2.7ms for 2 periods per buffer (same amount as 64 frames reduction)
Combining both lower buffer size and sync mode reduces latency by 4ms (this needs to use 3 periods per buffer though, otherwise the audio/i2s cannot cope with it)
PS: For those wondering what āsync/async modeā isā¦
Basically the audio engine we use (JACK2) uses an async audio model by default, where the audio renders to a non-active buffer and plugins that were able to finish rendering on time get their buffer copied into the real/active one. This is to prevent misbehaving plugins from causing audio glitches, the audio from such plugins will just not be used. So on a parallel chain of plugins, audio still keeps running except for the chain that includes the bad plugin.
The latency added by this async mode is the same as one audio period.
When using sync mode, the plugins render directly into the active audio buffer. This has lower latency, but makes xruns much more noticeable (one bad plugin can ruin the entire audio graph, even if disconnected)
9 Likes
thanks for these insight. always highly interesting!
These are very interesting and good news!
Should we expect this to be an user option in the UI in a future release? How does it look like for the MOD Dwarf?
2 Likes
Yeah, is it possible to test it on dwarf?
We are still evaluating things for the dwarf, could be it will be an identical situation to the Duo X, but it is a bit early to tell.
Cool! IMHO you should try to keep global latency under 3ms, it would be a killer factor for live situations. If bottleneck is jack, is it possible to investigate alternative solutions replacing it?
2.7ms is already the block latency for 128/48kHz, going for sub 3ms in actual in-out physical latency means running at 32 frames or less.
It is just not worth it for the CPU.