How does the Mod Duo X compare to the Raspberry Pi 4?

The title says it pretty much.
While I’m yearningly waiting for my Duo X, I’m playing with the MODEP on a Raspberry PI 4.
Until now it seems like I can build everything I ever dreamed of, including 8 channel audio input via USB. But will it be the comparable with the Duo X? I couldn’t find comparable benchmarks.

Bonus: How does the latency compare with the patchbox OS? I tried stripping it down to only MODEP + dependencies + SSH running and the audible result (I didn’t any measurements yet) for things like layering a kick was pretty good. I already used DSP hardware effects wich worse latency…

(talking here about the new duox model, which is what you can buy today and will begin shipping very soon)

We did not make a comparison, but even when the CPU and other specifications would be the same, the performance for the MOD OS would be slightly better due to the entire OS being optimized for a specific device.
MODEP uses raspbian as a base right? The RT kernel certaily helps, and also removing everything not needed for audio and MIDI.

On paper, compared to the Pi4, the Duo X has 2 more cpu cores (the A53 “little” cpu of the A72/A53 big-little combo)

I can give you some stats regarding the Duo X, that you can compare with what you have.
Would be quite interesting to see how MODEP behaves, so please run these same commands and paste the output.

First, measuring “worst case latency” / jitter:

$ cyclictest --smp -p98 -D30s

policy: fifo: loadavg: 6.12 4.61 2.23 7/136 1416

T: 0 ( 1380) P:98 I:1000 C: 29990 Min: 4 Act: 4 Avg: 5 Max: 28
T: 1 ( 1381) P:98 I:1500 C: 19993 Min: 4 Act: 5 Avg: 5 Max: 20
T: 2 ( 1382) P:98 I:2000 C: 14995 Min: 4 Act: 4 Avg: 4 Max: 19
T: 3 ( 1383) P:98 I:2500 C: 11996 Min: 4 Act: 4 Avg: 5 Max: 18
T: 4 ( 1384) P:98 I:3000 C: 9996 Min: 5 Act: 10 Avg: 8 Max: 42
T: 5 ( 1385) P:98 I:3500 C: 8568 Min: 5 Act: 10 Avg: 8 Max: 24

2nd, boot time:

$ systemd-analyze time

Startup finished in 2.219s (userspace) = 2.219s

(this boot time includes starting usb gadget mode, jack, ttymidi, mod-host, peakmeters, CV stack and mod-ui as well)

and I am not sure what else to measure…
the MOD devices run at a static 48kHz / 128 audio rate, which is around 5ms internal latency (but ends up being more in reality because of JACK2 async mode plus a tiny bit of the I2S side of things)

from what I understand, I2S has less latency compared to USB

1 Like

Thanks for your answer!

The audio is configured with 48kHz/128 as well. I think the I2S latency is not so relevant for me because I’m planning to use the same USB interface (Behringer XR18) with the MOD. But of course this means some additional latency for me.

For the cyclictest:

$ sudo ./cyclictest --smp -p98 -D30s
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 1.48 1.59 1.25 1/199 1716

T: 0 ( 1707) P:98 I:1000 C:  29991 Min:      6 Act:   17 Avg:   11 Max:      49
T: 1 ( 1708) P:98 I:1500 C:  19994 Min:      6 Act:   12 Avg:   10 Max:      56
T: 2 ( 1709) P:98 I:2000 C:  14995 Min:      6 Act:   10 Avg:   10 Max:      35
T: 3 ( 1710) P:98 I:2500 C:  11996 Min:      7 Act:   10 Avg:   11 Max:      62

It looks like the Rockchip with your optimized kernel is quite superior. I thought that Raspbian is already optimized to the Paspberry Pi but maybe it’s somehow limited due to the different hardware revisions.

The bootup time is not really comparable. There’s a lot going on and something of it is hardware specific (like the SD card service). Other things can still be optimize but I didn’t because I either couldn’t manage to disable certain things (this patchbox-init service is a bit ugly) or I need the services at the moment (gonna deactivate network once I got some monitor). Here’s a breakdown:

$ sudo systemd-analyze blame
         17.956s dhcpcd.service
          7.233s dev-mmcblk0p2.device
          6.852s hciuart.service
          1.872s patchbox-init.service
          1.158s systemd-udev-trigger.service
          1.023s rpi-eeprom-update.service
           839ms dphys-swapfile.service
           826ms systemd-journald.service
           795ms systemd-timesyncd.service
           657ms keyboard-setup.service
           607ms avahi-daemon.service
           591ms networking.service
           533ms systemd-fsck@dev-disk-by\x2dpartuuid-3ac474d7\x2d01.service
           469ms systemd-logind.service
           408ms fake-hwclock.service
           399ms user@1000.service
           393ms plymouth-start.service
           380ms kmod-static-nodes.service
           375ms sys-kernel-debug.mount
           339ms systemd-fsck-root.service
           321ms systemd-modules-load.service
           298ms systemd-remount-fs.service
           295ms cpu_performance_scaling_governor.service
           281ms alsa-restore.service
           278ms dev-mqueue.mount
           268ms rng-tools.service
           258ms rsyslog.service
           216ms systemd-journal-flush.service
           208ms systemd-udevd.service
           201ms systemd-tmpfiles-setup.service
           175ms ssh.service
           173ms run-rpc_pipefs.mount
           150ms triggerhappy.service
           133ms systemd-random-seed.service
           121ms systemd-update-utmp.service
           115ms systemd-sysctl.service
           115ms systemd-sysusers.service
           109ms systemd-tmpfiles-setup-dev.service
           105ms sys-kernel-config.mount
           100ms systemd-rfkill.service
            88ms bluetooth.service
            79ms ifupdown-pre.service
            76ms console-setup.service
            73ms systemd-update-utmp-runlevel.service
            61ms plymouth-read-write.service
            60ms user-runtime-dir@1000.service
            58ms nfs-config.service
            54ms systemd-user-sessions.service
            52ms boot.mount
            51ms systemd-tmpfiles-clean.service
            50ms plymouth-quit-wait.service
            41ms proc-sys-fs-binfmt_misc.mount
            38ms plymouth-quit.service
            37ms rc-local.service
            30ms modep-mod-host.service

Additional question: Do you think that additional USB audio interfaces would add (siginificant) additional latency or overhead to the system?

I’m thinking about connecting Elektron devices to the Duo X directly (there’s an experimental Alsa implementation available here) for getting more flexibility with the outputs and saving some A/D conversion.

that systemd-analyze kinda hurts to see :frowning:
dhcp takes waaay too long, plus the MMC is not supposed to take this long either.

The Duo X is using so-called eMMC (internal MMC soldered into the unit), which is mostly like an MMC.

For comparison and why not, on the Duo X the system-analyze gets us this:

$ systemd-analyze blame
          1.517s boot-operations.service
           895ms enable-usb-gadget.service
           645ms jack2.service
           420ms set-irq-priorities.service
           235ms controlchaind.service
           109ms systemd-fsck@dev-mmcblk0p5.service
            93ms data-partition-operations.service
            90ms systemd-logind.service
            77ms avahi-daemon.service
            72ms network.service
            60ms systemd-udev-trigger.service
            52ms systemd-user-sessions.service
            48ms mod-noise-removal.service
            36ms dnsmasq.service
            26ms systemd-udevd.service
            22ms systemd-fsck-root.service
            21ms systemd-remount-fs.service
            14ms dev-mqueue.mount
            12ms kmod-static-nodes.service
            12ms data.mount
            11ms systemd-sysctl.service
            10ms sshd.service
             9ms sys-fs-fuse-connections.mount
             8ms systemd-tmpfiles-setup.service
             8ms systemd-tmpfiles-setup-dev.service
             6ms tmp.mount
             5ms systemd-update-done.service
             5ms var.mount
             5ms sys-kernel-config.mount
             5ms root.mount

(boot-operations is a custom service that initializes hardware and restores mixer levels, it has stuff made in python, which makes it slower than the rest)

Regarding your last question: We do not officially support extra USB audio devices (only MIDI), but with some manual setup it should be possible to get them working.
There is no extra latency (of the main system) by having that, and the overhead it causes on a CPU like the A72 one is quite small.

This is something we will revisit near the end of the year for the Dwarf release.

1 Like

Sure, you can’t support everything possible with your hardware. I bet that there will be some guy how wants to add HID input or DMX lighting support or such. :smiley:
But still sounds promising. I definitely gonna try this… looks like I have to learn some stuff about kernel development.

I own Modduo and a Pisound with patchbox, i prefer Patchbox for the software flexibility, i can use pianoteq with raspberry 4 4gb (good perfs), but Modep is not as good as on Modduo regarding the hardware and software, on modduo you have a nice solid box, buttons, screen etc… If you have Patchbox for traveling or home it’s ok, for gigs Modduo is better. But if you own a midi controller Modep is cool too. For performance Modep can make large pedalboard with a lot of FX without cpu 100% use. Berry4 is faster to my advice vs Modduo. So better to own the two devices :wink: One thing cool is Touchosc with Patchbox and the wifi hotspot. So you can’t really compare they are differents (a lot of things i would see on modduo software are in Modep/patchbox).

2 Likes

Same patch/pedalboard loaded on Modep and Modduo, waited to stabilise cpu, no playing. 79% on Modduo cpu usage 21% on raspberry… So if you want power buy a Pisound Card and box.

2 Likes

Or a Mod Dwarf/X :wink: This thread is about the newer hardware generation. There’s no doubt that the RPI4 outperforms the Duo.

Yes but when it goes out Raspberry 5 will be out :wink:

Indeed, you cannot really compare a Pi 4 with a quad-core 1.5GHz to a Duo dual-core 1.0GHz…
No matter how optimized the Duo is, it just can’t really compare.

What we can compare though, is the same pedalboard using a Duo X.
Here is my result:

So kinda the same.

1 Like

So the Guy asked and now we can say it’s the same power as duoX (Missing pianoteq ;p) , but it’s an other thing. Can’t really compare these devices, like i said better to own a Duo or duoX and a Raspberry too, good combo.

Would be extremely happy about some of the ideas proposed here to be realized .
At the moment I’m trying to manually build some mod plugins for my raspberry pi 4.
Trying to use plugin builder on an Ubuntu VM to see if I get there.

For people who don’t have enough resources at the moment to spend on the great hardware gear like modduox would be awesome

1 Like

Isn’t modep stuck at some earlier versions? The one from blokas labs.
I managed to build the plugins in mod plugin builder and they are up and running on latest mod software adapted to the pi 4 aarch64.
As far as I know patchbox OS is 32 bit only and modep an earlier fork of mod, but I might be wrong.
Would be up to run some tests on my pi if it’s of any interest.
Putting together a script forked from micahvdm adapting it to use the Pisound hat https://github.com/CarloCattano/mod-PiSound

3 Likes