Good to know. The OP did not mention whether jackd was used just to enable multiple audio devices, or because there are other JACK enabled applications being routed. If only for multiple device support then perhaps just switching to the ALSA backend is an option.
I do not see an option in the ALSA backend startup dialog to use a single device for both input and output, and also add an additional device. Is that still hidden and requiring a command line option to enable?
Yes. While you can select different devices for Input and Output, combining two (or more) full duplex devices is not configurable using the GUI.
(see PipeWire Multiple Devices HowTo - #2 by x42 for a quick reference on ARDOUR_ALSA_EXT)
Great! Thank you!
I got lost immediately though, in what appears to be a jumbled list of complete packages, libraries, and variations of both, none of which have the 0.6.1 version number.
Iāve compiled and installed from source before, but thereās always been some uncertainty about how this particular set of build tools works, and about undocumented dependencies with non-matching names (to get the missing library A, I need to install package B, but nothing I can find anywhere says that B provides A), not to mention the same versioning problem in the first place.
Otherwise a .deb package, PPA, or script would be about my speed. 
My original architecture was using Carla to host a TON of individual plugins and manage their individual connections via JACK. But beyond just a handful of plugins, that gets to be unwieldy in a hurry, especially since Carla has stopped preserving the positions of things in the patchbay and gives me a jumbled mess regardless of how I saved it. Still functional - all the connections are still correct - but not maintainable.
So I moved everything into Ardour. Should have done that to start with, given my familiarity with physical mixing consoles. Now, Carlaās patchbay (when I open it manually; itās not in the setup script anymore) is just a giant block for Ardour, and a bunch of I/O devices. Thatās it.
But, most of those I/O devices are not physical. Theyāre bridges to PulseAudio. Both directions. Because my web browser and OBSās global audio devices are still PA only:
And, I expect to change USB devices frequently (mics and speakers, same usage regardless), so my setup script and Ardour patches are designed to work together to make those changes ājust workā. Tell the script what I want to use this time (actually a set of wrapper scripts that each have a different set hardcoded to pass to the main one), and it connects those devices to the same JACK names, and Ardour picks up the same JACK names like nothingās different at all.
If thereās a better way to do that, please let me know!
Sorry, I should have put a direct link in for zita-alsa-pcmi:
zita-alsa-pcmi 0.6.1 tar file download
Doesnāt need much in the way of dependencies, just the ALSA library devel package for the main library, and pthread and librt for the apps that also ship with it.
Probably for the time being what you have is going to be the most reliable.
It sounds like Pipewire would probably be the simplest for what you need, it combines the features of PulseAudio and JACK. The problem with Pipewire is that it is under pretty fast development still, so if your distribution does not pick up updated versions really quickly you can get stuck with some annoying bugs for a while. I donāt know how quickly Ubuntu picks up new versions, but if you like running the LTS releases then probably you would have to figure out how to pull in just pipewire from the latest release. I have no idea how difficult it is to mix and match repositories like that in Ubuntu, but if I read your tone correctly it sounds like you would rather just keep a reliable working setup as opposed to playing with the newest packages and spending a lot of time getting your software back to working as well as it did before.
Hmmā¦ Itās not downloading. It tries to start, and creates the file, but itās stuck on 0B transferred and 0B/s.
Iāll try again later. Maybe the server is rebooting or something.
Okay.
Yeah, Iāve seen Pipewire coming for a while now, and it does look excitingā¦at least on paper. And yes, I do like to work things out once and then keep them working like that as long as I can. I think 22.10 is supposed to be the first Ubuntu to use Pipewire by default, but having played with it on a temporary machine, I canāt tell that thereās anything different. The current LTS is 22.04, which is what I have now.
Ubuntu is pretty conservative, which might be part of why itās so popular. It doesnāt have the latest bells and whistles, even through regular updates, but it works right out of the box and stays working. Other distros are more bleeding edge, but as you mentioned, the tradeoff for having the fancy new features when they first come out is that they tend to break too.
If you really want something that is not in Ubuntuās official repo - whether something thatās just not there at all, or a newer version of what is - itās still easy to add (provided that it exists), and then apt picks it up like anything else.
I did that with OBS so that I could get the next major version from what Ubuntu Studio LTS is apparently staying with. That then allowed me to use a newer version of one of its plugins that had the features that I really wanted.
And of course, there are direct downloads as well, that are not vetted by anyone except the user. That option is still open too.
Fedora switched to Pipewire as default over a year ago, and it is great as a PulseAudio replacement.
I have not switched my JACK use case to pipewire yet, but I think the latest versions have everything working except latency reporting.
This post from about a year ago has a video from Ardour user Unfa who produces a lot of how-to style videos about linux audio production, it is covers multi-device use:
Post with embedded Pipewire how-to video
The updated zita library is in the Fedora updates-testing repository now, and I just verified that it seems to fix the problem originally reported.
Still not downloading. Same symptoms.
Now THATāS cool! Canāt wait for it to be considered stable enough to just cram it into a random system and watch it work. Or for it to come preinstalled in a future release, already working in all of its intended ways and not just a hesitant replacement for one thing only. Maybe the next Ubuntu LTS???
Great!
I donāt know if this is a related problem or not, but I tried it temporarily with an HDMI TV, same version that has the mic too hot, and the TV was perceptibly silent. No errors, everything looked like it should have worked, including the exact name to create the JACK-to-PA bridge (*) and a meter immediately before the bridge. Even turned the TV way higher than it should ever be for anything sensible; still nothing. Both VLC and aplay directly to that name, without JACK running, worked just fine. (turned the TV back down; ouch!)
Didnāt pay too much attention beyond that, like listening closely to see if it was just that low (-48dB is a lot), but I wouldnāt be surprised if the level mismatch went both ways. Or maybe itās a different problem? I really donāt know.
(*) I apparently have 5 different HDMI audio outputs, all on the same CARD=NVidia,DEV=x, where x is 3, 7, 8, 9, or 10. Maybe itās counting the HDMI and DisplayPort on the laptop plus the dock ports separately, despite not being on the dock at the time? Anyway, I know that the laptop HDMI port has always been hw:CARD=NVidia,DEV=3 every time Iāve tried it. (which isnāt very often; I normally donāt have HDMI-connected speakers)
Tried it on a different TV. PulseAudio by itself still works just fine, and it still has problems via the bridge from JACK. (still the old version of zita) But instead of just silence, the bridge from JACK has 1/4 second or so of full-scale static every few seconds. (no need to turn this TV up!)
I got to thinking about this some more and wondering, since I have to manually reset OBSās video connections anyway when I go to a different location, maybe it wouldnāt be so bad to manually reset Ardourās audio connections as well. Still have Ardour using loopbacks to and from OBS and the web browser, but its connections to physical devices would now be direct.
Would that change the advice of how to do it?
Of course, PipeWire would make this all irrelevant, but until thenā¦
I keep saying that development is still happening quickly, but I realized I had not checked the changelist in quite a while.
Just saw this on pipewire.org:
Latency reporting is implemented since 0.3.29
The latest tagged version is 0.3.63, so that has been in for a while.
There is a note in the TODO that latency compensation is not implemented, but I am not aware that jackd ever performed latency compensation. I thought that jackd just reported latency, and it was up to the client applications to perform any compensation.
So maybe the last piece is in place now to have pipewire fully replace jackd for typical use cases. There are a few cases not supported, like netJACK, and I donāt know that pipewire will ever scale up to the crazy high channel counts that some of the universities were using in the multichannel studios, but I think latency reporting was the last thing needed for pipewire to be able to cover 90+ % of normal audio production needs.
Interesting. Maybe itās worth a shot then, to take an image of the hard drive just in case, and then see if I can switch over.
I noticed that Unfa has an update video about a month or two after the āWow, it works!ā one, saying that the latency problem would randomly and frequently crash Ardour, which made it unusable. Both videos are a few years old now. Donāt know what version he was testing either; he might have said, but if he did I donāt remember.
Finally got around to this again, and thereās been a few updates, so I thought Iād just try it and see if the fix has trickled down yet. It hasnāt.
Tried the download again. The updated browser gave me a big scary warning about security, instead of just quietly refusing, so I finally did get it to download. But now I have a different problem: how to build and install?
aaron@aaron-ubuntustudio-m6800:~$ cd ~/Downloads/Zita/zita-alsa-pcmi-0.6.1/
aaron@aaron-ubuntustudio-m6800:~/Downloads/Zita/zita-alsa-pcmi-0.6.1$ ls
apps AUTHORS COPYING README source
aaron@aaron-ubuntustudio-m6800:~/Downloads/Zita/zita-alsa-pcmi-0.6.1$ cd source/
aaron@aaron-ubuntustudio-m6800:~/Downloads/Zita/zita-alsa-pcmi-0.6.1/source$ make
g++ -O2 -Wall -fPIC -march=native -DVERSION=\"0.6.1\" -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -c -o zita-alsa-pcmi.o zita-alsa-pcmi.cc
In file included from zita-alsa-pcmi.cc:25:
zita-alsa-pcmi.h:27:10: fatal error: alsa/asoundlib.h: No such file or directory
27 | #include <alsa/asoundlib.h>
| ^~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [<builtin>: zita-alsa-pcmi.o] Error 1
aaron@aaron-ubuntustudio-m6800:~/Downloads/Zita/zita-alsa-pcmi-0.6.1/source$
The README doesnāt say anything about installing or dependencies, nor does anything else. As you said:
So Iām probably just missing the one ALSA-dev package, but what does apt call it for Debian/Ubuntu? Iāve seen some wacky unintuitive names before, with no correlation to what they provided, and Iāve seen others that (apparently?) had to guess a version number correctly.
Itās libasound2-dev
For librt and pthread itās librtr-dev and probably libpthread-stubs0-dev
It builds and installs now. Thank you!
aaron@aaron-ubuntustudio-m6800:~$ sudo apt install libasound2-dev librtr-dev libpthread-stubs0-dev
[sudo] password for aaron:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
librtr0 libssh-dev libssl-dev
Suggested packages:
libasound2-doc librtr-doc libssh-doc libssl-doc
The following NEW packages will be installed:
libasound2-dev libpthread-stubs0-dev librtr-dev librtr0 libssh-dev libssl-dev
0 upgraded, 6 newly installed, 0 to remove and 8 not upgraded.
Need to get 2,787 kB of archives.
After this operation, 14.4 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
...
aaron@aaron-ubuntustudio-m6800:~$ cd ~/Downloads/Zita/zita-alsa-pcmi-0.6.1/
aaron@aaron-ubuntustudio-m6800:~/Downloads/Zita/zita-alsa-pcmi-0.6.1$ cd source/
aaron@aaron-ubuntustudio-m6800:~/Downloads/Zita/zita-alsa-pcmi-0.6.1/source$ make
g++ -O2 -Wall -fPIC -march=native -DVERSION=\"0.6.1\" -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -c -o zita-alsa-pcmi.o zita-alsa-pcmi.cc
g++ -shared -Wl,-soname,libzita-alsa-pcmi.so.0 -o libzita-alsa-pcmi.so.0.6.1 zita-alsa-pcmi.o -lasound
aaron@aaron-ubuntustudio-m6800:~/Downloads/Zita/zita-alsa-pcmi-0.6.1/source$ sudo make install
install -d /usr/local/include
install -d /usr/local/lib64
install -m 644 zita-alsa-pcmi.h /usr/local/include
install -m 755 libzita-alsa-pcmi.so.0.6.1 /usr/local/lib64
ldconfig
ln -sf libzita-alsa-pcmi.so.0.6.1 /usr/local/lib64/libzita-alsa-pcmi.so
aaron@aaron-ubuntustudio-m6800:~/Downloads/Zita/zita-alsa-pcmi-0.6.1/source$ cd ../
aaron@aaron-ubuntustudio-m6800:~/Downloads/Zita/zita-alsa-pcmi-0.6.1$ ls
apps AUTHORS COPYING README source
aaron@aaron-ubuntustudio-m6800:~/Downloads/Zita/zita-alsa-pcmi-0.6.1$ cd apps
aaron@aaron-ubuntustudio-m6800:~/Downloads/Zita/zita-alsa-pcmi-0.6.1/apps$ make
g++ -O2 -Wall -MMD -MP -DVERSION=\""0.3.2"\" -c -o alsa_loopback.o alsa_loopback.cc
g++ -O2 -Wall -MMD -MP -DVERSION=\""0.3.2"\" -c -o pxthread.o pxthread.cc
g++ -o alsa_loopback alsa_loopback.o pxthread.o -lzita-alsa-pcmi -lasound -lpthread -lrt
g++ -O2 -Wall -MMD -MP -DVERSION=\""0.3.2"\" -c -o alsa_delay.o alsa_delay.cc
g++ -O2 -Wall -MMD -MP -DVERSION=\""0.3.2"\" -c -o mtdm.o mtdm.cc
g++ -o alsa_delay alsa_delay.o mtdm.o pxthread.o -lzita-alsa-pcmi -lasound -lpthread -lrt
aaron@aaron-ubuntustudio-m6800:~/Downloads/Zita/zita-alsa-pcmi-0.6.1/apps$ sudo make install
install -d /usr/local/bin
install -m 755 alsa_loopback /usr/local/bin
install -m 755 alsa_delay /usr/local/bin
aaron@aaron-ubuntustudio-m6800:~/Downloads/Zita/zita-alsa-pcmi-0.6.1/apps$ exit
This is a laptop and Iām not at the rig right now, so Iāll have to wait to see if it fixes the level mismatch.
No change. Iām using it like this, with commented options:
#!/bin/bash
...
echo "Use MIC0: $MIC0"
zita-a2j -j MIC0 -d $MIC0 -c $MIC0_CH -r 48000 &
#jack_load MIC0 --wait zalsa_in --init "-d $MIC0 -c $MIC0_CH -r 48000" &
PID_MIC0=$!
sleep 1
echo "Use SPK0: $SPK0"
zita-j2a -j SPK0 -d $SPK0 -c $SPK0_CH -r 48000 &
#jack_load SPK0 --wait zalsa_out --init "-d $SPK0 -c $SPK0_CH -r 48000" &
PID_SPK0=$!
sleep 1
...
I did find this though, that came with Ubuntu Studio, though itās a bit hard to find:
alsamixer CLI, so Iām pretty sure itās just a GUI wrapper for it. Anyway, my guess of -48dB wasnāt too far off. The faders for each channel seem to affect both channels though, and their effect is cumulative, but it does work. (as shown, both input channels are reduced by 40dB)
I still wonder what itās doing to the bit depth.
ā
Donāt know why I didnāt think of this earlier:
aaron@aaron-ubuntustudio-m6800:~$ zita-a2j
zita-a2j-0.8.4
(C) 2012-2018 Fons Adriaensen <fons@linuxaudio.org>
Use ALSA capture device as a Jack client.
Usage: zita-a2j <options>
Options:
-h Display this text
-j <jackname> Name as Jack client [zita-a2j]
-d <device> ALSA capture device [none]
-r <rate> Sample rate [48000]
-p <period> Period size [256]
-n <nfrags> Number of fragments [2]
-c <nchannels> Number of channels [2]
-S Word clock sync, no resampling
-Q <quality> Resampling quality, 16..96 [auto]
-I <samples> Latency adjustment [0]
-L Force 16-bit and 2 channels [off]
-v Print tracing information [off]
aaron@aaron-ubuntustudio-m6800:~$ zita-j2a
zita-j2a-0.8.4
(C) 2012-2018 Fons Adriaensen <fons@linuxaudio.org>
Use ALSA playback device as a Jack client.
Usage: zita-j2a <options>
Options:
-h Display this text
-j <jackname> Name as Jack client [zita-j2a]
-d <device> ALSA playback device [none]
-r <rate> Sample rate [48000]
-p <period> Period size [256]
-n <nfrags> Number of fragments [2]
-c <nchannels> Number of channels [2]
-S Word clock sync, no resampling
-Q <quality> Resampling quality, 16..96 [auto]
-O <samples> Latency adjustment [0]
-L Force 16-bit and 2 channels [off]
-v Print tracing information [off]
aaron@aaron-ubuntustudio-m6800:~$
Iām not sure what you were trying to point out there. That is the latest version, the problem we were discussing is in the zita-alsa-pcmi library, which is used by zita-a2j.
What you want to check is something like this:
$ which zita-a2j
/usr/bin/zita-a2j
$ ldd /usr/bin/zita-a2j
linux-vdso.so.1 (0x00007fffd9b39000)
libzita-resampler.so.1 => /lib64/libzita-resampler.so.1 (0x00007fb53eb15000)
libzita-alsa-pcmi.so.0 => /lib64/libzita-alsa-pcmi.so.0 (0x00007fb53eb0a000)
libjack.so.0 => /lib64/libjack.so.0 (0x00007fb53eab5000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fb53e800000)
libm.so.6 => /lib64/libm.so.6 (0x00007fb53e720000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb53ea95000)
libc.so.6 => /lib64/libc.so.6 (0x00007fb53e543000)
libasound.so.2 => /lib64/libasound.so.2 (0x00007fb53e433000)
libopus.so.0 => /lib64/libopus.so.0 (0x00007fb53ea38000)
libdb-5.3.so => /lib64/libdb-5.3.so (0x00007fb53e264000)
libsamplerate.so.0 => /lib64/libsamplerate.so.0 (0x00007fb53e0f4000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb53eb5d000)
$ ls -lh /lib64/libzita-alsa-pcmi.so.0
lrwxrwxrwx. 1 root root 26 Dec 28 01:18 /lib64/libzita-alsa-pcmi.so.0 -> libzita-alsa-pcmi.so.0.6.1
The first command (which) verifies the full path to the zita-a2j application (in the event you have more than one executable, it shows the file found if you just type the name at the command prompt without a full path).
The next (ldd) shows the dependencies of that file, i.e. which shared libraries it uses.
The Unix tradition is that when you have a compatible shared library that is a new version, you use a symbolic link from the actual file with the name of the base shared library. In this case zita-a2j is found to rely on libzita-alsa-pcmi.so.0 so the āls -lhā command shows the long version of the file attributes, which displays that my file libzita-alsa-pcmi.so.0 is actually a symbolic link to libzita-alsa-pcmi.so.0.6.1, which is the version with the fix.
Check those steps on your system and verify which alsa-pcmi library is actually being used by your zita-a2j application.
Aha! Iām still using 0.4.0:
aaron@aaron-ubuntustudio-m6800:~$ which zita-a2j
/usr/bin/zita-a2j
aaron@aaron-ubuntustudio-m6800:~$ ldd /usr/bin/zita-a2j
linux-vdso.so.1 (0x00007ffc054e2000)
libzita-resampler.so.1 => /lib/x86_64-linux-gnu/libzita-resampler.so.1 (0x00007f9d5a057000)
libzita-alsa-pcmi.so.0 => /lib/x86_64-linux-gnu/libzita-alsa-pcmi.so.0 (0x00007f9d5a04d000)
libjack.so.0 => /lib/x86_64-linux-gnu/libjack.so.0 (0x00007f9d59ff8000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9d59ff3000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f9d59dc9000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9d59ce2000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f9d59cc0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9d59a98000)
libasound.so.2 => /lib/x86_64-linux-gnu/libasound.so.2 (0x00007f9d59995000)
libdb-5.3.so => /lib/x86_64-linux-gnu/libdb-5.3.so (0x00007f9d597e6000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9d5a08a000)
aaron@aaron-ubuntustudio-m6800:~$ ls -lh /lib/x86_64-linux-gnu/libzita-alsa-pcmi.so.0
lrwxrwxrwx 1 root root 26 Jan 12 2022 /lib/x86_64-linux-gnu/libzita-alsa-pcmi.so.0 -> libzita-alsa-pcmi.so.0.4.0
aaron@aaron-ubuntustudio-m6800:~$
Is it just a matter of redirecting the link then? I thought the make install step should have done that, but I guess it got the wrong directory.
Yes, just redirecting the link should work. When your distribution provides the new version from the repositories I think it should just over-write your changed link, and everything should keep working.
If I understand correctly what happened, the issue is that you have a zita-a2j installed from your distribution repository, which would use /lib/x86_64-linux-gnu as the location for distribution installed libraries, but your locally compiled version installed into /usr/local/lib64.
That looks like the correct place to put locally compiled software per the filesystem hierarchy standard, but it gets a bit tricky when you have a distribution package manager and you want to change just one part of a change. For example in your case you would like to replace just the distribution zita-alsa-pcmi library, but keep the zita applications. If you attempt to remove the distribution provided zita-alsa-pcmi, the package manager will likely complain that zita-a2j relies on that library, and so attempt to remove the application as well.
The two ways around that are to just ātrickā the system into using the version you compiled without letting the package manager know, or make a new package (e.g. a deb file) and install the newer version using a custom updated package file. I assume at some point the distribution package will be updated (although you may be able to speed that up by filing a bug report requesting the update), so making your own package may be more trouble than benefit.
It works!
aaron@aaron-ubuntustudio-m6800:~$ sudo mv /lib/x86_64-linux-gnu/libzita-alsa-pcmi.so.0 /lib/x86_64-linux-gnu/libzita-alsa-pcmi.so.0.old
[sudo] password for aaron:
aaron@aaron-ubuntustudio-m6800:~$ sudo ln -sf /usr/local/lib64/libzita-alsa-pcmi.so.0.6.1 /lib/x86_64-linux-gnu/libzita-alsa-pcmi.so.0
aaron@aaron-ubuntustudio-m6800:~$ ls -lh /lib/x86_64-linux-gnu/libzita-alsa-pcmi.so.0
lrwxrwxrwx 1 root root 43 Mar 28 09:12 /lib/x86_64-linux-gnu/libzita-alsa-pcmi.so.0 -> /usr/local/lib64/libzita-alsa-pcmi.so.0.6.1
aaron@aaron-ubuntustudio-m6800:~$ 00_Live_Show_Meeting/test.sh
...
Use MIC0: hw:CARD=U192k,DEV=0
Use SPK0: hw:CARD=U192k,DEV=0
Starting synchronisation.
Detected excessive timing errors, waiting 10 seconds.
...
Donāt know if excessive timing errors means anything, but I do get the correct level now, and it sounds good. (the whole rig takes more than 10 seconds to finish setting up, so that part is fine) Thank you!
test.sh:
#!/bin/bash
...
echo
echo "Use MIC0: $MIC0"
zita-a2j -j MIC0 -d $MIC0 -c $MIC0_CH -r 48000 &
#jack_load MIC0 --wait zalsa_in --init "-d $MIC0 -c $MIC0_CH -r 48000" &
PID_MIC0=$!
sleep 1
echo "Use SPK0: $SPK0"
zita-j2a -j SPK0 -d $SPK0 -c $SPK0_CH -r 48000 &
#jack_load SPK0 --wait zalsa_out --init "-d $SPK0 -c $SPK0_CH -r 48000" &
PID_SPK0=$!
sleep 1
...
I guess I can delete the commented alternative too.
Or could use it in place of an external program. I think jackd is using the same zita-alsa-pcmi library, so the internal client should be fixed as well.