Zoom U-22 Linux review (be cautious of pulseaudio at 96khz)


This is the Zoom U-22. It’s a 96Khz/24bit USB audio card for Windows and Mac.

There’s 2 things that strike out as interesting here:

  1. No testing on Linux has been done for this DAC.

  2. They suggest against using this DAC with AMD chipsets.

To get a few things out of the way:

Yes, it works in Linux at 96khz/24bit. (I recommend using the tsched=0 fix to adjust your audio buffer size)

Yes, it works on the USB ports directly going to the processor on Ryzen. (Not the ASmedia ports, the 3.0 ports going directly to the CPU)

There is one massive caveat though:

Anytime the device is re-initialized on pulseaudio’s end, you get a cyloning effect. This is most apparent when you change sound input/output configs in KDE settings, or if you launch OBS without killing Pulseaudio.

If you encounter “cyloning”, kill pulseaudio with pulseaudio -k in Terminal.

To get OBS working, you must kill pulseaudio first, then launch OBS. If you already launched an audio program and OBS re-initializes the DAC using a scan, you get cyloning.

Be prepared to use that command a lot, and finding what order to launch programs that won’t cause the DAC to cylon upon recording or playback…

TL;DR: Yes it works on Linux, but be prepared to use pulseaudio -k a lot at 96khz.

Edit: A firmware update to version 1.1 did not fix cyloning.

However, using 48000hz sample rate does not have the cyloning issue when launching OBS or changing stuff in KDE settings. Using 96000hz sample rate causes the cyloning. What this means is the maximum sample rate has issues with cyloning and pulseaudio, but it can be fixed by killing pulseaudio.


tsched=0 disables timer-based scheduling
audio buffer settings are default-fragments and default-fragment-size-msec
in daemon.conf
archwiki has information showing how to calculate values needed:
Setting the default fragment number and buffer size in PulseAudio
formula for fragment size is based on
sample-rate * sample-format * sample-channels:
44100 * 16 * 2 = 1411200 bps
48000 * 24 * 2 = 2304000 bps
96000 * 24 * 2 = 4608000 bps

on an OS with systemd, better to restart Pulseaudio with:
systemctl --user restart pulseaudio
usual kill command will restart Pulseaudio but with a different server path and missing modules loaded at boot
can see the changes in pasystray

device would probably work better for 24bit/96kHz in JACK

I would appreciate some testing to see if the cylon issue goes away in JACK, cause I have no clue how to set that up without majorly screwing up my system. The programs that have to work are OBS and KDE’s audio backend.

JACK doesn’t work with OBS unless OBS is built with JACK support, but then you also have to route it specifically in order to get audio from the desktop. It was already a deep rabbit hole to get it working, but it doesn’t work OOTB with neither OBS or KDE’s sound mixer.

Trying to get it working is beyond any reasonable person’s capacity. Pulseaudio is easier to troubleshoot. But I’m not downplaying anyone getting it working on JACK. If you do get it working with JACK, I’d love to see your setup with this thing. (I got it for $100CAD, so it’s great for entry level stuff.)

i have not spent much time using OBS, but i worked out replacing Pulseaudio connection to JACK for a friend to try video streaming his radio shows
i am reinstalling my old desktop in a week or two so will do a JACK/OBS setup and start another linked topic to post data and screenshots

‘cyloning’ is not a term i have heard before. if it is similar to an online bandwidth issue increasing fragment-size setting would be equivalent to increasing bandwidth

pulseaudio default configuration is a safe-minimum. good for working on even old devices. but modern audio hardware can sound much better with a few changes

no need to change defaults /etc/pulse/daemon.conf
make changes in home folder to file ~/.config/pulse/daemon.conf
(if it goes wrong delete custom file and restart to get back on default)

suggest try something like my configuration (except the last setting)

# ~/.config/pulse/daemon.conf

## Custom Configuration file for PulseAudio daemon. 
## See 'man pulse-daemon.conf' for more information. 

resample-method = speex-float-5
default-sample-format = s24le
default-sample-rate = 48000
default-fragments = 4
default-fragment-size-msec = 16

i have an internal pro-audio card which came out very low on fragment-size calculation
you will probably need a larger value there
calculation is not always reliable so may help to try a few other values

to check new configuration and settings - pulseaudio --dump-conf

The cyloning I almost am certain is because it’s set to 96000hz, but then OBS for a single sample changes Pulseaudio to 48000hz without polling the hardware, resulting in that chip tune “cyloning” where the sample rate is wrong.

I can’t be bothered with JACK because it screwed up my Davinci Resolve installation. Had to re-install to get stuff working again.

Me either but at a guess @FurryJackman do you mean like the noise the Cylons make in Battlestar Galactica? Sorry I no help otherwise but being able to relate the sound to something other people can hear might help if they have come across the noose somewhere else and know what makes it or how it could be made.

It’s common on TWiT’s podcasts whenever someone uses a Cmedia chipset headset.

there are CMedia CMI codecs on internal cards known to be useless for analog audio capture; but have good audio capture for SPDIF that many cards do not have
if audio capture is generally bad like this it would be at all sample-rates

USB interfaces can cause strange audio effects for listener if using zero-latency monitoring mixed with mic audio playback from system (with delay from longer trip)
if delay time is short microphone will sound will have a ‘comb filter’ like a flanger/phaser guitar pedal
but this would be only the mix heard by user (at all sample-rates)
with only one audio stream in pc, audio would be ok on any recording/VOIP call etc

as problem is only at high sample-rate, still appears to be some bottleneck in audio stream that cannot cope with 2 or 4 * number of bits than lower rates
most likely would be buffer size
possibly choice of resample-method

may help to bypass Pulseaudio and test playback direct to ALSA
speaker-test or media player like audacious that can play to ALSA) and bypass

Got a lot on my plate right now so I don’t know if I’ll be able to get to that. Direct ALSA might work if Pulseaudio is completely disabled, but Wine still likes Pulseaudio and most of my games run on Proton…

usually only need to Suspend Pulseaudio or set device profile to ‘Off’

initial premise of review did not mention wine; proton, Davinci Resolve

i was thinking this was a Linux review based on the title
was curious to see if device would work ok in JACK
maybe find out if preamps within device are any good
have seen unverified comments that suggest Zoom devices do not have enough preamp gain
for use with some microphones

Definitely enough for condenser mics, but not enough for dynamic mics.

Unfortunately, it looks like USB 3.0 controllers (the NEC/Renesas ones) don’t play nice with the U-22 in Linux.

dmesg is flooded with messages like this:

[   56.027066] xhci_hcd 0000:07:00.0: ERROR: unexpected command completion code 0x11.
[   56.027071] usb 3-2: Not enough bandwidth for altsetting 1
[   56.027073] usb 3-2: 1:1: usb_set_interface failed (-22)

And ASmedia keeps throwing error -110 constantly, eventually completely failing just like previous experiences with Fresco Logic controllers on Linux.

VIA controllers without IOMMU on seems to be stable, but it doesn’t work for VFIO, so it’s only if you intend to simply use it without VMs.

This cannot be fixed as XHCI on Linux has been in a severely neglected state for non-chipset USB 3.0 controllers. (Fresco Logic, NEC/Renesas, ASmedia). Using a Hub also doesn’t work if it didn’t work with a direct connection on these controllers.

You must plug the U-22 into a USB 2.0 ONLY port when using it on Linux on a platform that doesn’t have native USB 3.0 over the chipset. The B450 chipset doesn’t suffer this issue with the 3.0 ports going to the CPU or the chipset, but it has the same issues if you use the ASmedia ports. (typically the USB 3.1 Gen 2 and the motherboard USB 3.0 header)

This will also be true of any full bandwidth 480mbps high-speed USB DACs on USB 3.0 controllers that are not the AMD or Intel CPU/Chipset on Linux. Avoid ASmedia, NEC, Fresco Logic for these cases.

The Zoom H5 does not suffer from this problem on XHCI controllers on Linux.

hey, anyone has any ide why might a zoom u-22 has dropouts on my windows 10 x64 pro…?

Buffer issues, CPU to Memory latency issues, DPC latency issues, low quality USB cables… lots can factor in here.

BTW, I figured this out. Both default AND alternate sample rates in daemon.conf had to be set. if you leave alternate commented out, it falls back to 48000 and causes the issues.

I’m curious if you’ve tried passing any of these through to windows guests (via KVM)…

Do not use NEC/Renesas controllers. Only native Intel or native AMD controllers work. Asmedia as described above is a total miss.

Is there a a chart of which audio interfaces have which controllers? Seems like all of the regularly recommended ones are fine and there isn’t much of a pro/con of any of them (Focusrite, Behringer, Steinberg, etc).

Unfortunately not many have torn down their interfaces to find out the chips inside. Teardowns of newer audio interfaces are pretty few and far between.