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.
Now it’s working. Now I have slightly too many channels 
. But I’m verry happy this is working and I’m able to start to mess around with this setup.
Thank you for your help!
Wow @rolego seems impressive… A “tutorial for rookies” would be great 
, I’m sure lots of users would love to have this, specially the ones with Duo X which has more muscle to do this kind of things…
This is something I see a lot of potential, as Rolego said, The Duo X is something very “studio oriented”, and being able to route instuments via USB to the Duo X and effect them is great, or at least take out the synth instruments of the Duo X separated from the 2 instruments you can have.
Dear @danielrm
Yes, to be honest, the current configuration of Duo X does not make much sense in my eyes: that much power and possibilities while being limited to two audio channels. Especially in a DAWless or live situation this is very limiting.
In my eyes supporting class compliant USB interfaces (maybe restricted to a certain number of devices, maybe restricted to the number of channels) would be a compelling feature for a device that is designed to be used on the desk where in most cases one would have more than one audio (source-) devices and would like to get the signals separately after FX. But according to @falkTX the team does consider this as “not a very common usecase” and thus I do not expect support for this in the future.
But anyway: I’ll write down a tutorial on how to do this even if I don’t think this is a sustainable setup as it could be broken with any future update.
you were correct in what you said, except this part.
Once we deal with the dwarf USB audio, adding support for this will be quite simple since it will be reusing the same system components.
But that only takes cares of the behind-the-scenes stuff. To make this feature viable, it needs to have some options on the UI (for setting up a few things like buffer size and bitrate).
These are great news! To work until then with an experimental setup is fine for me as long as I do not have to fear to invest to a dead-end.
Good to hear that! I think it makes all the sense, I mean in the Mod Duo which was a “guitar-oriented stompbox” I could say “ok, I’m trying to use it in other way, it’s normal that it’s not prepared for that”…
But in the DuoX… I mean, we all love that machines like the Digitakt or the Octatrack have separated channels for their sounds in USB, and the DuoX is generating sounds with its synths, samplers… I thinks it’s a very natural and good way to improve the machine.
