Currently using a Behringer UMC202HD, stereo XLR preamp on USB (U192k in the screenshot below), and the built-in audio on a laptop (PCH). But depending on where I am at the moment, the XLR preamp could be replaced by some USB wireless mic receivers, or who-knows-what-else.
The built-in audio is the only consistency here, so I’d like to keep it as the primary. That makes it easy to pass the present set of devices into a script that sets up and tears down this rig, which in turn passes them to zita-a2j and zita-j2a. Everything else stays the same. The same Ardour session connects right up to a different set of physical devices because their JACK equivalents (created by zita) are identical.
The relevant part of the script is:
#!/bin/bash
# Removed: Error-checking
MIC0=$1
shift
MIC0_CH=$1
shift
SPK0=$1
shift
SPK0_CH=$1
shift
# Removed: "Interview" for detailed configuration, if not passed as subsequent arguments
echo
echo "Looking for MIC0: $MIC0"
until arecord -L | grep "$MIC0" > /dev/null
do
sleep 1
done
echo "Found MIC0: $MIC0"
echo "Looking for SPK0: $SPK0"
until aplay -L | grep $SPK0 > /dev/null
do
sleep 1
done
echo "Found SPK0: $SPK0"
# Removed: Start JACK and configure bridges to PulseAudio
echo
echo "Use MIC0: $MIC0"
zita-a2j -j MIC0 -d $MIC0 -c $MIC0_CH -r 48000 &
PID_MIC0=$!
echo "Use SPK0: $SPK0"
zita-j2a -j SPK0 -d $SPK0 -c $SPK0_CH -r 48000 &
PID_SPK0=$!
# Removed: Remaining setup including Ardour, wait for done, teardown
echo
echo "Unuse SPK0: $SPK0"
kill -TERM "$PID_SPK0"
echo "Unuse MIC0: $MIC0"
kill -TERM "$PID_MIC0"
# Removed: Undo the PulseAudio bridges and stop JACK
Anyway, even after swapping the primary and zita devices, zita is always about 48dB too hot, and the primary is fine. The PA bridges are also good. 48dB is roughly the dynamic range of 8 bits, which originally made me suspect that it’s taking the lower 16 bits of a 24-bit number.
But I’m pretty sure that the built-in audio is only 16 bits to start with, and it’s still ~48dB too hot when running through zita. So maybe there’s something else going on?
At any rate, it would be nice to have all devices working correctly.
Since version 1.9.18 the equivalent of zita-a2j has been built into jackd v2 (it was present in jackd v1 for much longer, but most distributions ship jackd v2).
You may try using the internal client instead of the version of zita-a2j. I don’t remember exactly how that gets started, but I think you use jack_load zalsa_in to load it as an internal client.
You do not mention the versions of either, that would usually be the first relevant information (in this case version of jackd and version of zita-a2j).
The author of the zita tools (Fons Adriaensen) often participates in the linux audio users mailing list, posting there may get some debugging advice.
I’m kinda lost there. I think I’m fairly decent with electronic circuitry and low-level embedded software (for the purpose of simplifying the circuitry), but I’d consider myself mostly a “script-kiddie” for very much beyond that. (copy-paste things that work, without much understanding why. I want to know why, but most of it just doesn’t “click” for me. It’s annoying.)
Google isn’t helping much either. It might be a case of knowing the right terms…at which point the help isn’t really needed either.
Except for adding OBS’s direct PPA to get a newer version with features that I needed, this is stock Ubuntu Studio 22.04 LTS, fully updated. Whatever version of things that comes with…
How to find out?
I’ve signed up, but I don’t have the confirmation email yet. Checked spam, it’s not in there.
I don’t use Ubuntu so I’m not familiar with their tools. The underlying package manager should still be apt, so there should be some apt command to show the versions from CLI, but Ubuntu probably has a graphical package manager as well to show you what versions are installed on your system.
aaron@aaron-ubuntustudio-m6800:~$ apt-show-versions jackd
Command 'apt-show-versions' not found, but can be installed with:
sudo apt install apt-show-versions
aaron@aaron-ubuntustudio-m6800:~$ sudo apt install apt-show-versions
[sudo] password for aaron:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
libapt-pkg-perl
The following NEW packages will be installed:
apt-show-versions libapt-pkg-perl
0 upgraded, 2 newly installed, 0 to remove and 4 not upgraded.
Need to get 103 kB of archives.
After this operation, 333 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://us.archive.ubuntu.com/ubuntu jammy/main amd64 libapt-pkg-perl amd64 0.1.40build2 [72.5 kB]
Get:2 http://us.archive.ubuntu.com/ubuntu jammy/universe amd64 apt-show-versions all 0.22.13 [30.5 kB]
Fetched 103 kB in 0s (223 kB/s)
Selecting previously unselected package libapt-pkg-perl.
(Reading database ... 472709 files and directories currently installed.)
Preparing to unpack .../libapt-pkg-perl_0.1.40build2_amd64.deb ...
Unpacking libapt-pkg-perl (0.1.40build2) ...
Selecting previously unselected package apt-show-versions.
Preparing to unpack .../apt-show-versions_0.22.13_all.deb ...
Unpacking apt-show-versions (0.22.13) ...
Setting up libapt-pkg-perl (0.1.40build2) ...
Setting up apt-show-versions (0.22.13) ...
** initializing cache. This may take a while **
Created symlink /etc/systemd/system/timers.target.wants/apt-show-versions.timer → /lib/systemd/system/apt-show-versions.timer.
apt-show-versions.service is a disabled or a static unit, not starting it.
Processing triggers for man-db (2.10.2-1) ...
aaron@aaron-ubuntustudio-m6800:~$ apt-show-versions jackd
jackd:all/jammy 5+nmu1 uptodate
aaron@aaron-ubuntustudio-m6800:~$
I guess I have version 5+nmu1, with no updates available? That doesn’t mean a whole lot to me, but maybe it does to you?
You could try the built in client. I don’t have access to a machine running jackd that I could try at the moment, but I think it would be something like:
jack_load MIC0 zalsa_in -i “-d hw:U192k -r 48000”
You might have to play around with the arguments and check the man page and google some examples, jackd development is stretched very thin so the documentation is not as obvious as perhaps it could be.
According to that, it appears that your guess is pretty close. Conceptually (to me at least) take the command zalsa_in -d hw:U192k -r 48000, which specifies an input device and sample rate, and put a wrapper around it called jack_load that first takes the name that JACK should call it, and some other optional arguments, and then the wrapped command.
But:
aaron@aaron-ubuntustudio-m6800:~$ man zalsa_in
No manual entry for zalsa_in
aaron@aaron-ubuntustudio-m6800:~$
and Google doesn’t help there.
Running it anyway produced this (from Google’s manpage, I thought the -i was superfluous; turns out not):
aaron@aaron-ubuntustudio-m6800:~$ jack_load MIC0 zalsa_in "-d hw:U192k -c 2 -r 48000"
jack_load: invalid option -- 'd'
usage: jack_load [ options ] client-name [ load-name [ init-string]]
options:
-h, --help print help message
-a, --autoclose automatically close when intclient is unloaded
-i, --init string initialize string
-s, --server name select JACK server
-w, --wait wait for signal, then unload
aaron@aaron-ubuntustudio-m6800:~$ jack_load MIC0 zalsa_in -i "-d hw:U192k -c 2 -r 48000"
zalsa_in is running.
client name = MIC0
aaron@aaron-ubuntustudio-m6800:~$
That got me a connection, same as zita, and still way too hot.
I don’t see a difference. Everything is S32_LE regardless, including the internal audio, which is surprising to me. I guess it could be higher-quality, but I think it would be wasted on this hardware. Software-consistency, maybe?
Anyway, the problem remains that JACK’s primary device is fine, and the additional one is too hot.
Likely just because it is an efficient interface for the driver. 32bit per sample makes it easy and efficient to use on CPUs (regardless that there are not actually 32 bits of valid signal).
–
To ask the obvious. Have you checked with alsamixer that the levels of the device are set correctly? Perhaps some mic-boost is enabled?
I haven’t looked at that specifically, but I’ve seen enough else that I’m pretty sure it’s not the problem:
This mic is a 2-channel XLR preamp with optional 48V phantom power. (48V is needed for one of these mics) So the “mic-boost” in this case is a physical knob. (and a pad button for line-level signals) I set it originally with Audacity’s meters without JACK, so Audacity was looking more-or-less directly at the device. And when used as JACK’s primary device, Ardour also shows the correct level. All of this agrees with the signal and (absence of) clip lights on the preamp itself. (I can make it clip, to show that the light works, but I do know not to keep it there!)
Using it as a secondary device - zita or jack_load, either one - gives the way-too-high meters and gross distortion unless I turn the physical gain knobs way down and use the pad button. I can get it to clean up that way (and still have about the same signal-to-noise ratio, which tells me that the dominant source of noise is still the room, even at such a low electronic level), but the physical signal lights no longer come on. And of course I’d rather set the physical gains “correctly” and leave them there.
Switching the tools back to direct (Audacity without JACK, or JACK primary in Ardour), with the lower physical setting, also has the meters way down, which agrees with the absence of the signal lights. Through all of this, I never changed anything in PulseAudio or ALSA, except to create and remove the bridge to JACK.
The same path-dependent levels also apply to the built-in mic: without JACK, or as JACK primary, it’s as-expected, but through zita or jack_load, it’s way too hot. No change to its mic-boost, which is a software setting in that case.
Looked at alsamixer. It’s just a more granular version of the system tray controls, in that it splits out the mic-boost and attenuation settings, whereas the tray controls manage both automatically for an overall result. I can see one moving when I move the other.
And the setting doesn’t seem to do anything anyway, for the USB stuff. The only meter that responds to it is the internal mic.
You can select which device has the audio data modified in ALSAMixer with the F6 key. If you only see the built in sound card, likely you can press F6 and select the USB device.
I don’t know of any reason that ALSAMixer settings would change beween jackd direct and the jackd zalsa internal client, so really just exhausting all the possibilities.
That’s what I meant. F6 to the USB one, see the setting change, but the meter doesn’t.
Actually I have two USB audio devices at the moment. The other one is an HDMI capture that carries the camera mic, which I’m not really interested in. So it took me a while to figure out what the other list item was. Same there: it has an input gain/attenuation control, but it doesn’t seem to do anything to the meter.
It’s been a week and a half since I signed up for the Linux audio user mailing list, and I still don’t have a confirmation e-mail. So I did it again, with the same password, and I got the same moderation page that says:
Your subscription request has been received, and will soon be acted upon. Depending on the configuration of this mailing list, your subscription request may have to be first confirmed by you via email, or approved by the list moderator. If confirmation is required, you will soon get a confirmation email which contains further instructions.
I guess we’ll see if it works this time.
Meanwhile, I still don’t know what to look for about the non-primary mic levels. Whatever is primary is okay, and everything else is still about 48dB too hot, or about the dynamic range of 8 bits. No other settings change.
I’ve been slammed at work the last few weeks, but I will hopefully get a chance to try out your configuration this weekend and see if I can duplicate what you see. I’m not sure what is the next step if I cannot, but if I can duplicate the problem then that is at least a start.
I verified the same or almost same behavior on my Fedora installation with jackd 1.9.21.
Also verified that the internal zalsa_in client and zita-a2j 0.8.4 behave the same.
I just posted the observation to Linux Audio Users list (Christmas evening US time). The original author and a lot of the LAU members are in Europe, so getting late in the evening there. Maybe in the next couple of days someone there will have an idea what is going on.
The author of zita-a2j responded very quickly on the Linux audio users list, and it turned out to be an error in the zita-alsa-pcmi library which is used to interface to the ALSA devices for zita tools and derivatives. He has a fixed version, 0.6.1, available already: Zita software downloads
I’m not sure what level of comfort the OP has with the Ubuntu packaging tools, rebuilding a local package with the new version is one option to get going until the Ubuntu repositories pick up the new version.
The same library is used in Ardour for adding additional auduio devices when using the ALSA back end, and I see that Robin already checked in the fix to the Ardour source code just a few hours ago.
I submitted a bug report to the Fedora bug tracker to get the package updated in the Fedora repositories, I would recommend someone do the same for Ubuntu so the existence of a new version gets noticed more quickly (and so that the package maintainer is aware of the severity of the error in the existing package).
@GMaq might be interested in picking up this fix as well.
Ardour’s ALSA backend was not affected by this though.
The code was based on an older version of zita-alsa-pcmi (0.3 from 2012), and also modified (Ardour/ALSA allows for separate playback/capture periods, supports more channels, and can fallback to nearest available fragment size). But for good measure I’ve updated the relevant part to recent zita-alsa-pcmi 0.6.1.
