It’s not possible to run jackd with sync mode and ‘-p 128 -n 2’ at the moment, but ‘-p 128 -n 3’ works.
The current setup is what we can do in a stable way with the current driver and sunxi-3.4 RT kernel.
When we move to mainline we’ll revisit this.
If you’re playing in a small venue or in a studio the effect is more noticeable. Especially if you’re playing with headphones. I think these use cases fit most of the amateur musicians. In the case of a guitar, the faster you pick the more evident the latency gets. If Malmsteen is playing with a MOD with headphone I’m pretty sure he’ll notice =)
Therefore I see margin for improvement as I noticed it myself (hence driving me to do the measurement).
Moreover it could affect the development of some effects that require early reflections. A colleague of mine was looking for a dev board with 5ms latency for instrument modeling.
@falkTX is it right to assume that ‘-p 128 -n 3’ would result in the same latency as of now?
roughly the same yes, around 0.3 ms less with ‘-n 3’ sync mode.
not worth it at all.
interesting, where do those 0.3ms difference come from?
Good question.
I don’t know at this point, it was just what jack_iodelay reported.
Tell your colleague about bela: http://bela.io
Less than 1ms in to out latency for audio, for analog 20us in to out.
I have one here with the extra audio expander, so 6 audio ins and outs all at less than 1ms end to end. Its a nice piece of kit.
You need a BeagleBone Black to attach it to, buffer size is one sample the majority of the time is the ADC/DAC conversion.
The Bela is something completely different, it uses a separate RTOS to do the DSP. This does give you sub 2ms latency but it also limits the possibilities, especially when compared to the Duo.
Whats that got to do with a guy looking for a low latency dev board?
I would strongly advice the mod team to change the info in the FAQ if the measurements by @edwillys is still valid. For me the latency is very important and nudging info in this way doesn’t impress anyone.
“We use specific PCBs and circuits for audio processing, producing a latency of approximately 5 milliseconds, which is imperceptible to humans…”
For me “approximately” is faaaaaar from the right word to use if the stated value is 37.5% less than the actual value!
2 Likes
Duly noted!
We have a new website coming out soon and we’ll have this corrected 
1 Like
(and it’s also corrected now in the website and wiki FAQ)
1 Like
Will LV2 plugins compile to the Bela kernel libc? It looks like libpd runs with modifications for that hardware.
UPDATE: Looks like the answer is yes with some manual compiling
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.