@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.
5 Likes
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?
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.
4 Likes
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.
1 Like
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:
- I connected a class compliant USB Audio interface to the USB-A connector
- aplay -l returns this:
[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
- in
/etc/mod-hardware-descriptor.env- I set
SOUNDCARD=USB. - The property
JACK_DEVICE_EXTRA_ARGSwhich was mentioned by @Klaustrophil was not in my file but I added it just to be sure.
- I set
-> 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.
1 Like
Thanks for your reply, @falkTX
But unfortunately this did not solve it. Strangely there was no if statement around the export…