I’m aware that this is pretty unsupported terrain so feel free to decline an answer
Maybe someone else is interested in this topic as well.
I’m still exploring the MOD software on MODEP until my Duo X finally arrives. Multiple inputs with an USB audio interface are already working like a charm and I have a good idea how things working. My next step is connecting multiple audio interfaces at once.
Without touching the MOD software, only the ALSA device aggregation is possible. I created a config similar to the example to merge my Elektron Analog Heat with the Behringer XR18:
This config is basically working with sending audio from the XR18 to the AH and back. However there are some serious artifacts in the audio output which are gradually fading in and out over time. I’m not that deep into this topic yet but it sounds like the audio clock is drifting. If this is actually he case, I guess this method is pretty much dead?
I’m not sure if the logic is fully handled there but it was the closest match I could find. However, it looks like a trivial change could make this work for a proof of concept.
a custom alsa config will not work well for jack. jack wants direct hardware access, which is not possible with such config as there will be a middle layer of alsa plugins in between.
in the future, the way we are going to do something like this is to bring the zita-a2j/j2a as jack internal clients (done already in jack1, not yet in jack2) and trigger a jack_load as needed.
do note that you can set alsa_in/out name as “mod-slave”, and those will appear in mod-ui
but the jack2 version in MOD units is a custom one, suited mostly for internal clients. alsa_in does not work as-is without env var tricks.
Whereby also with the “audioadapter”, I wrote something about it on linuxmusicians, the audio clock must be synchronized if the 2 - X interfaces should not drift.
Thanks for the input!
Now it’s getting interesting. You better stop reading here
For the records: I’m hacking around in the code right now because mod-slave as port name is not working properly. The host component somehow confuses the first two inputs with the additional two added by zita-ajbridge. And the outputs are not working because of the way how the port names are compared. First I thought it’s just 2 lines of Python but it’s getting more complex. The current architecture clearly isn’t made for this. Looks like some of this is also hardcoded in the libmod_utils C++ bindings. If this is meant to get more flexible in the future, a better data structure for port management is needed. But I guess that you will refactor many of this in the mid terms anyways?
and mod-ui shows the extra ports as expected, everything seems to work.
wherever audioadapter is reliable or not is a different matter, I did not test that yet.
Ok I think I gonna postpone this until I got the Duo X environment.
The current fork you are working with seems to be somehow incompatible with the MODEP environment and I don’t want to waste the time of everyone including me to figure out the differences or what are the Blokas guys are exactly using.
The MOD fork enables the internal client optimizations by default, to avoid context switches when processing the plugins.
All of MOD stuff (mod-host, peakmeter, ttymidi, cv tools) run as internal clients.
MODEP likely uses external (started from CLI rather than being attached to jack as “plugins”), which these optimizations do not work well against. (a special CLI env var needs to be set in order to deactivate the optimizations temporarily so the external clients can run)
