More audio inputs?

Thanks for the suggestion, but in my particular use case at hand the idea is to have the DUO X take over the function of a small mixer; space is very limited. Also, I think netjack2 would have to run over wi-fi, which is far from ideal for that, and would add considerable latency - which I think it would also if ethernet was a possibility.

the netjack2 solution uses the USB connection between the MOD and the PC.

The induced latency is very small.

Hi together,
to change soundcard settings one has to SSH into the MOD Duo and is responsible for any changes themselves.

Today the zita-a2jbridge (for adding a ALSA soundcard as a Jack node) is not compiled for and available on the Duo. But zita-j2n and zita-n2j (for adding a computer on the network as a Jack node) are available. Please study their man pages. @crosswick I confirm a class compliant USB soundcard will not work in tandem with the internal soundcard of the Duo running release 1.6.

Replacing the internal soundcard with an external USB device works on a early experimental level. At least drivers are compiled into the kernel.

Using network connections does not add to the latency itself. But you might be forced to double the buffersize to avoid XRUNs. I expect WiFi to be very unpredictable unreliable, for example because of the Hidden Node Problem. I you experiment with audio over network, be sure to try what happens on packet loss, reconnection join or if any Jack application starts to freewheel (for example Ardour exporting faster than realtime).

Best regards


Wifi ?

@Azza Could you please ask more specific? I don’t know the answer to "“WiFi”.

1 Like

Sorry, I was on my phone and could not type much.

In your previous post, you are saying “I expect WiFi to be very unpredictable unreliable”. Sorry to ask, but how is wifi involved in the process here ?

I see. Thanks for explaining.
I have not had time to look, if the driver for a USB-WiFi-Adapter is actually build into the kernel of the Duo; probably not.
Thinking about routing over standard network connections, it is possible to route UDP packets (containing audio) from the Duo over the USB connection to your computer, then bridge it to a WiFi adapter and from there it could possibly go anywhere on the internet. My point is, if you have a dedicated LAN under your control, I expect to transfer audio with almost no XRUNs. Once a WiFi link is included in the network, there are no guaranties it might work.
Short: Technically you could involve WiFi…but don’t do it.
Please feel free to ask again, if I did not answer your question.

Ok, I think we are mixing two different discussions here.

My interest in using Wifi (stated in a different thread) is simply to be able to use the mod GUI from any device on the LAN.

Now, this particular thread is about adding mode inputs to the Duo, and my comment above was that the user could use the particular audio interface of their PC (for instance, my workstation has got 8 input and 8 outputs), and use netjack (through the usual USB cable link, nothing to do with WIFI) to route the signal from their PC interface into the MOD for processing only and then back out to the PC for output via the PC soundcard.

Alternatively, the user could take the MOD out of the equation by just running the MOD software on their PC, for instance, by using the nice KXStudio linux distribution, the mod-host and mod-ui packages (don’t forget to set the MOD_APP and the MOD_LIVE_ISO environment variable before launching mod_host and mod_ui executables).

thank you

This is exactly what I want to do. I got a digital mixer which also acts as an USB audio interface. If this hack works, I’d use this device as a 6-channel multi-send effect in a live environment. (Which would save a lot of space, cables, weight and D/A conversion)

Has anyone actually tried this yet?

Sorry, I am not sure I understand the setup you have in mind.

No problem! I was a bit tired writing this.

I got a Behringer X Air 18 digital mixer. This mixer can act as a 18x18 audio interface. This allows me to send/receive audio to/from the host system. This is freely routable. In my use-case this means:

The XR18 has 4 internal effects which can be used as (stereo) send-effects. But the routing can be overwritten to a different destination. So instead of sending the signal from a channel to the internal effect, I want to send it to the Mod Duo X via USB. There I want to process it and return it to the XR18. So on the Mod Duo X I need to reconfigure some stuff (At least ALSA and Jack I guess) to use 8 channels of the XR18 as the input source as well as the return path.

In my performance I want to send channel 8 to a EQ; distortion, compressor, channel 9 to a EQ, compressor, gated reverb, EQ; channel 1,2,5 and 6 to a delay + reverb; the mixer sum to a reverb.

And yes, I’m aware of the limited resources of the Mod Duo X and maybe 8 channels are too much with multiple reverb etc.

Has anyone tried USB audio routing part so far?

Apart from the possible problem of performance, what I think is a problem here is weather the Mod Duo X embarks the driver for your XR18. Apart from that, you should be able to tweak alsa/jack to use your XR18 instead of the Mod Duo X embedded interface.

I can say that the XR18 works fine on my Laptop which is running Manjaro Linux without any changes in ALSA. But I don’t know the peculiarities of the Mod Duo distribution. And then there’s also the software of MOD Devices which could have hard coded values or other assumptions about the underlying audio configuration.

Therefore my question if anyone has practical experience with this.

The Mod comes with quite a bare version of the kernel…

Apart from that, have you tried running the Mod software on your laptop ?

JACK is running inside the unit as the audio-server, it is hardcoded to use the internal soundcard, for obvious reasons.
It is possible to run extra external soundcards, of course, as well as replacing the JACK command to use the external card instead of the internal one.
But since it is not a very common usecase, there is no support “out of the box” for this.

The main issue with external cards is clock drift.
But if a few bad samples are okay, then this is doable even as a plugin.


Thanks a lot for this answer! Now it’s even harder to wait for my Mod Duo X :slight_smile:

If I understood it right, this means that there’s some minor jitter in audio? How does this affect the audible experience in a live setting? And wouldn’t it always be a problem as long as there’s no clock to sync all audio devices which are processing audio?

1 Like

I could imagine this is a common use case indeed and would give Duo X mind-blowing possibilities.
Duo X is designed to be used “on the desk” where one often finds several instruments or tracks: some keys, synths, beat, vocals… With just 2 channels it’s impossible to use the Duo X for single tracks separately (e.g. for creative effects) and some effects on the sum. Being able to add for example 8 additional inputs by pluging in a USB interface would be so useful.


I received my Duo X today and can finally start hacking now. My first goal is making it work with my XR 18.

For this reason I changed the following two lines in /etc/mod-hardwaredescriptor.env


This was kinda working. But for some reason I got audio output on more channels than expected. When I route the audio to the channels 1 and 2, I also got output on 3 and 4.

Then I somehow fucked up the device after I forgot to sync the write to the environment file before turning the device off. Or at least that is what I’m suspecting as root cause. This screwed up the content so I decided to do a hard restore. Interestingly, the firmware on the USB device (genius idea btw!) has the same version as the installed one but a higher build number.

After I got it back running, I couldn’t get it to start with the same modifications. The problem here was that there are some hardcoded dependencies around mod-amixer and it’s return values. Making it inaccessible to mod-ui fixed the startup issues.

Now I’m back again with the screwed channel mappings. :joy:

//Edit: Ok it seems like channel 1+2 are duplicated to 3+4 for some reason. All channels from 5 - 18 are working just fine.

haha, yeah, this is for very specific reasons :sweat_smile:
explained in a future update later on, please be patient, and it is better not to change that line.

each one of our builds is counted. the one you have comes from factory with a self-test enabled, the user-reset one has it disabled.

you will have better luck changing the jack-usb-gadget systemd service.
dont know how good it behaves with usb soundcards though, for now that script is only there for internal testing, it is not a published feature yet. only by the end of the year we will make it so, our focus right now is on other things.

1 Like