I had some time to measure the input/output latency of the MOD Duo. A screen shot of the measurement below:
As you can see, the latency is about 8ms.
- Computer outputing a -6dB square wave @50Hz through analog 3,5mm jack.
- 3,5mm stereo to 2x jack adpter, out of which one goes to MOD Duo Input 1 and the other one to the channel 1 of the oscilloscope (yellow curve in the pic above).
- MOD Duo set to bypass Input 1 to Output 1. SW version is 1.3.0.
- Output 1 from MOD Duo going to channel 2 of the scope (blue curve in the pic above)
- Red curve represents the multiplication of channel 1 and channel 2
The frequency of 50Hz was used since I assumed the latency was lower than 10ms. I repeated the test with 30 Hz and achieved the same result.
- The 8ms are a little above of the 5ms mentioned on the FAQ.
- The slope on the output betwen 0 and 1 states of the square wave. This is probably due to the analog circuitry.
Let me know if you have also done some similar measurements.
I’m no electrical engineer so I apologize for my ignorance but when the mod is set to bypass, isn’t this a so-called true bypass so there’s an analogue connection from input to output, and wouldn’t we expect latency in that state to be virtually zero? Or is the mod in this experiment not bypassed but with the input directly connected to output in software?
This is the latency of the AD (audio to digital) converter, then, the signal is pass to jack, and then back to the DA (digital to audio) converter.
So, this is the latency you will get as well with any given padelboard.
When it gets higher you’ll receive a Xrun (lost audio data). It will never be shorter, as this time frame is given by the chosen settings in jack.
The 5ms mentioned in the FAQ seems to be the latency introduced by jack, the time frame were plugins could work with the data, the additional 3ms been used by the converters.
Looks like a reasonable test with reasonable results to me.
Or is there really a physical (true) bypass?
Even if there were a true bypass this wouldn’t be relevant for the audio processing effects, since they have to go through the audio chain. Therefore the ‘soft’ bypass is the meaningful one. I agree with @brummer that the 5ms look like the buffering delay. Probably the 128 samples ping pong at 48kHz. However 3ms for ADC and DAC seems too much to me and would mean the magical number of 2ms could never be achieved.
just to restate what edwillys said, he didn’t measure the mod’s bypass, but rather when the input is connected directly to the output on the mod pedalboard (soft bypass). The mod is true bypass (when its unplugged you get sound through it) but it wouldn’t tell very much to measure that. Measuring the soft bypass tells you the minimum latency you can get when using the mod effects with the current configuration (and some effects will add more latency).
I’m a little surprised by these results too, especially the slope on the square wave. It almost seems like there was an overly-heavy DC blocking filter on it. 8ms latency is plenty good for guitar though.
Thanks for the measurement, that’s very consistent with the actual settings. The MOD runs
jackd -R -P 80 -d alsa -d hw:MODDUO -r 48000 -p 128 -n 2 -X raw
With jack2 (async by default), the nominal round-trip latency is
128 * (1 + 2) / 48000 = 8.0 ms which matches your measurement. So there is no systemic latency.
PS. if you launch
jackd -S ... or use jack1, the nominal round-trip latency would be 5.33 ms. In case of the MOD the soundcard is using i^2s/i^2c with DMA (no additional kernel buffers), the codec (hardware) latency is on the low usec scale (it’s a CS4245).
PPS. for a good explanation sync/async and periods see http://lists.linuxaudio.org/pipermail/linux-audio-user/2012-May/084743.html
Thanks for the snippet and the link! I wondered about the +1 latency but it is explained by the async mode. Maybe @falkTX could comment if there is any progress on reducing this or if the -S has already been experimented. I would tend to disagree with @ssj71 and say that 8ms is a bit much for guitar. You can actually feel it on the attack of the pick on the strings.
Can you feel 8ms in a way that distracts you?
8ms – that corresponds to 2.75m of sound in air. Most guitarists move around a lot more around on stage.
Acoustic guitar lap to ear is about half of that. There are very few musicians who notice or can’t cope with 10ms latency.
Humans are a lot more sensitive to jitter though (variations of latency). There are not many studies on the subject. One that comes to mind is http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0127902 which measured 20ms as common fluctuation for hi-hat onsets and snare/hh concurrency.
PS. It’s different for vocalists (sound via bones to ear vs AD/DA latent headphone). So if you use the MOD for vocal-processing with a headphone and without direct monitoring of the dry-path. Maybe 8ms is not good enough.
As for async/sync mode. In sync-mode the realtime-constraints are tighter. Effectively you’ll have a higher worst-case DSP usage for the same pedalboard or x-runs become more likely.
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?
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!
We have a new website coming out soon and we’ll have this corrected
(and it’s also corrected now in the website and wiki FAQ)
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