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 
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?
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
SOUNDCARD=X18XR18
[...]
JACK_DEVICE_EXTRA_ARGS="-C hw:${SOUNDCARD} -P hw:${SOUNDCARD}"
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. 
//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 
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.
Dear @Klaustrophil
I intend to do technically the same, but in my case with a Elektron Analog RYTM (8-Channel Drum-Synth). Thus I wanted to ask if you gathered some more experience with this setup which you would like to share.
Does, btw, the builtin soundcard gets replaced with this modification in the config?
Did you experience the clock drift @falkTX mentioned?
Dear @Klaustrophil and @falkTX
I’m trying to get this work, but did not succeed so far. Maybe you could give me some hints:
[root@modduox ~]# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: DUOX [MOD DUOX], device 0: 30010000.sai-cs4265-dai1 cs4265-dai1-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: USB [Scarlett 18i20 USB], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0
/etc/mod-hardware-descriptor.env
SOUNDCARD=USB.JACK_DEVICE_EXTRA_ARGS which was mentioned by @Klaustrophil was not in my file but I added it just to be sure.-> now the device does not boot completely: The screens remain “MOD DUO” / “X”.
What am I missing?
yeah, this is completely unsupported!
but… edit /usr/bin/mod-ui.run and remove the lines
if [ -n "${SOUNDCARD}" ]; then
export MOD_SOUNDCARD=${SOUNDCARD}
fi
so the webserver will not try to manage the soundcard anymore.
Thanks for your reply, @falkTX
But unfortunately this did not solve it. Strangely there was no if statement around the export…
It is there for 1.9, so you are not running things up to date?
No, unfortunately I had to downgrade since I have a very early “Limited Edition” Device which has some instabilities with 1.9 
Can you be more clear? Most of the things I know about are fixed now.
And 1.9.3 coming up in a few minutes
The unit often got stuck during boot (MOD DUO / X) screen. Sometimes I had to reboot it several times until it finally worked.
I contacted support and Salvador told me this is a known issues in 1.9.2 some old devices have which will be fixed. He suggested me to downgrade to 1.8 until then.