But might very well end up being the case.
The compromise is that lower latency = more cpu load = less plugins that can be loaded overall.
@unbracketed please correct me if I am wrong, but in Bela’s case only very specific sounds can be loaded right? can it handle more than 1 PD file? and use externals? (problem with PD seems to always be the externals haha)
From a guitarist point of view, loading no more than 6-7 plugins could be enough. With this limitation if it would be possible to reach 2-3ms latency it would be great. I know Duo X can currently load a lot of heavy plugins simultaneously but I suspect in most real use cases it will lead to unused CPU power. If that low latency could be obtained sacrificing CPU power and selected via UI settings would be a huge feature! I mean something like “Check this flag for low latency (no more than x% CPU usage is allowed or no more than X plugins are allowed)”.
We understand that, thanks for the continued feedback.
As I said before, this was something that was never too viable for the Duo, so we did not research it much.
For the Duo X and Dwarf, it makes sense to give some options.
We will do some tests and discuss this in the team.
I highly appreciate the use of well known technology like ALSA and jack. It makes a lot of fun hacking around in the system and makes it a LOT more valuable. Since the computing power constantly grows, I’m sure that we could half the latency in a few years 
Is there anything else I should do except for setting the buffer of jack to 64 for testing it by myself on the Duo X?
you can change /usr/bin/mod-jackd as that is the script that starts up jack.
the “-S” option param is already there, set if reading a file, but since it did not work so well on the Duo it also enables the extra alsa period buffer when doing so.
I think if you look at the file you will understand quickly
I’ve just upgraded my Duo to the latest 1.9.1 with mainline kernel - is this likely to affect latency positively or negatively? Thanks.
Negatively, by around 0.4ms I think.
There is something that is mainline kernel is doing regarding i2s that adds a tiny bit of delay somewhere, but I could not find out where or how exactly 
I think we can live with that 
I know it’s been a long time since the last post, but as I’m waiting for my Dwarf to arrive, I’m wondering if there are any updates regarding it’s latency. Is the option for 64 samples available on its settings (or on the Duo X for what is worth)? 
Not at this point in time.
But something we will be investigating for sure
I’d like to test running my dwarf in 64-frames. Honestly I do haven’t been using my dwarf much because most of the playing I do nowadays is online (I use a special Motu AVB interface on my computer which I can get down to a millisecond roundtrip latency with 6-frame or 12-frame sized buffers). But I avoid including the mod when jamming online because while the latency from 128-frames is fine on its own, however when added to the networking latencies it pushes it too high.
I guess I would have to ssh into my mod to change the latency down and change it in some jack config file. Could it at least be added to developer mode in the webgui to make it easier for users to test?
We would need to do some stress testing before showing such option.
We began with just disabling async jack processing mode, which generally works but somehow makes the cabinet simulator plugins misbehave.
The dwarf can run at 64 frames, but cpu is going to be quite limited with that (think 2x-3x less the amount of plugins you can use right now). Some of the plugins were made with only 128 or 256 frames as supported buffer size, so they can misbehave.
So we do not expose this option right now. If you want to get your hands dirty, the file that sets this up is /usr/bin/mod-jackd, controlled by the jack2 systemd service.
Basically, regarding latency (full audio IO roundtrip) stats are:
@falkTX: How does this compare to the MOD Duo X? Do we have a similar decrease in performance and misbehavior of the cabinets?
Not being an expert on this matter (and maybe @falkTX can correct me if I’m wrong), I would say that yes, since both devices run the same platform and the plugins side of things tends to be exactly the same on both. I say “tends” on purpose, since some plugins sometimes have weird behaviours between devices and that needs to be fixed on the specific device where it acts weird.
Just a quick question:
I wanted to try “64 frames, 3 periods per buffer, sync mode”, which seems to be the fastest latency that Mod Duo X can handle (from seeing this post).
So, after reading /usr/bin/mod-jackd, I realised I can set 64 frames by doing touch /data/using-64-frames and turn on sync mode by doing touch /data/jack-sync-mode. But then I found that it doesn’t work. And then I was looking for a similar option for 3 periods per buffer, but I couldn’t find it in the /usr/bin/mod-jackd file.
Could I ask if there is an easy way to turn on 3 periods per buffer? Thanks in advance.
Try one option at a time.
The “sync” option already reduces roundtrip latency by 1/3 (from 8 to around 5ms), that typically should be enough.
The sync+64frames mode ought to work though, only doesnt on old Duo 3.4 kernels.
I tried sync, which worked, and then did 64 frames, which stopped it from working. So I was wondering if it was not working because periods/buffer was set to 2, which was why I wanted to try periods/buffer 3.
This was for my Mod Duo X (production unit) when I used it as an audio interface.
And in terms of latency, I’m trying to reduce it much as possible because I have a MIDI pickup with latency like ~10ms ish by itself, so any cut in latency would be really beneficial.
The way to reduce latency, as it seems to me, is to write custom code to deal with USB and ALSA together.
Typically ALSA needs 2 sets of audio buffers - one on the card and the other being “scratch” buffer. They get swapped around when the audio cycle ends. Much like double-buffering and swap as done for video.
As far as I know, there is no getting around this for i2s, which the Dwarf uses as audio interface. This basically means any audio cycle latency is basically at least double that in the final stage. So 128/48kHz is 2.6ms, and double that is 5.3ms which is the absolute minimum latency possible on a regular ALSA 128/48kHz device like MOD uses. (the actual real latency ends up being around 5.7ms, there seems to be about 0.4ms introduced by the linux system)
Now, because of how we setup the USB audio interface - an external process that receives audio from the host, puts it into a buffer, and then another thread fetches that buffer to give to ALSA + USB interface… this is just too many steps of buffering and latency is 4x more than it should.
It allows us to test if audio works well, but yeah it is not good in terms of latency. The extra buffering also wastes CPU.
The alternative is to switch to how ALSA + USB is setup in this external program, so that instead of being ALSA asking for audio (aka “pull model”, the typical way to do audio drivers) we can instead directly push to ALSA + USB which if I am not mistaken will write directly into the USB buffers.
This will avoid extra buffering, we just receive audio from the host and directly feed it into the USB side. Since the host audio runs in realtime, it kinda works as a precise timing mechanism, which is required for USB audio.
This is all in theory though, still need to actually write down some code to confirm this. PIpeWire has managed to make it work, so there is precedence.
As a bonus, if this works well enough, it should be suitable to use in a plugin. So we could get extra audio IO support via plugin (i mean, using a usb audio card for extra IO on a MOD device, not just MOD itself as audio device)
Thanks for the thorough explanation, @falkTX.
Ultimately, I believe MOD has to make a business decision as to whether or not fully implementing USB audio is worth your time. I understand it’s almost there, but with the constraints you now face – not to mention the dreadful prospect of developing new hardware for at least the next 3-5 years, given shortages and skyrocketing prices – you may find out that putting your manpower into something that may not see widespread approval and be too burdensome on your hardware may actually work against you.
Not trying to be nosy here, but I would think this is a worthwhile reflection.