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.
There are several ways to accomplish this as pointed out here: https://jackaudio.org/faq/multiple_devices.html
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:
description "Merged interfaces"
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?
This means I’d have to stick with using either
alsa_out to accomplish this and hoping this yields better results. At the moment it looks like the MOD software is ignoring every jack port which is not starting with
system as I spotted there: https://github.com/moddevices/mod-ui/blob/a03b7d91314d329b3dc86ec992a3994a13c8d5bf/mod/host.py#L2596
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.
Am I on the right track?
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.
Jack2 also offers an “audioadapter”.
that is actually a very good point!
jack2 has some many undocumented features, even I forget that they exist sometimes.
audioadapter does seem to work (at least start) even in duplex mode.
will test this properly at some point, no time for that now.
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?
just do not use capture_ and playback_ prefixes on external client ports, and all will be well.
for my tests with the audio adapter, I changed this:
the card can then be loaded like this:
jack_load mod-slave audioadapter -w -a -i "-d hw:1 -p 128 -n 3"
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.
How do you implement the synchronization of the 2 - X audio/MIDI interfaces?
(Why can I not publish links here?)
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.
Thank you so far for all the hints!
anti-spam feature for new accounts. post some welcome friendly messages and soon should all be good.
sorry for the trouble
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)