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
1 Like
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:
- now/current: 8.443ms (async, 128 frames)
- sync 128 frames: 5.776ms
- async 64 frames: 4.443ms
- sync 64 frames: 3.110ms
5 Likes
@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.
1 Like
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)
8 Likes
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.
2 Likes
This is surely a worthwhile investment of time, it is just more a question of timing.
And also if someone else does it first, as these kind of projects tend to be opensource in nature anyway.
I did a lot of stuff on my own free time for my own things (KXStudio, Carla, DPF among others) that ended up extremely helpful for the MOD platform.
DPF is now the go-to framework to use when developing plugins for MOD, which ends up being useful for developers too because it can do VST2 alongside LV2, sometime next year likely supporting VST3 as well.
That is to say, it is just a matter of time between:
- someone (not me or MOD) does a tool that does what I described in my previous post, and we can just repackage it
- a time comes until MOD needs it, and working hours are spend developing this tool
- I get bored with other stuff and just do it as a challenge
I imagine by the end of the year one of those will come true 
15 Likes
Good to hear that, @falkTX.
Mind you that I am not against it, but was just wondering how much manpower would be necessary to make it happen versus addressing other needs/improvements across your lineup. Likewise, I am not critical of MOD’s decisions or how you or anyone there specifically employ their time. My only wish is that MOD as a platform acquires a footprint large enough that more plugin developers choose to develop either specifically for the MOD or at least LV2.
What I meant with “business decision” is not the material investment of it, but the search for adequate balance whereby wants, needs and musts can be properly addressed. Even humanitarian aid has to bow at times to factors such as local difficulties, pressures, dealing with local forces, logistics, bureaucracy, and the list goes. Hope I did not offend you or anyone.
PS> Carla is a great tool, btw. All props to you!
5 Likes