[Hardware] ZOOM UAC-8 driver/backend for Ubuntu 24.04 (Direct JACK bypass, looking for testers!)

Installation & Configuration Linux
#1

Hi everyone,

I created a driver/backend setup for the ZOOM UAC-8 audio interface on Ubuntu 24.04.

Key feature:

It directly bypasses ALSA and connects straight to JACK for optimal communication.

If anyone here has the same audio interface, I’d really appreciate it if you could test it out and let me know if it works for you!

Any feedback, bug reports, or success stories are welcome!

Screenshot_20260815_023223
Screenshot_20260815_023223801×559 125 KB

Thanks!

#2

Ummm, I don’t think so. Just in case this claim sounds plausible to somebody, that is literally a contradiction to how the stack works. JACK talks to ALSA, never directly to hardware.

1 Like
#3

With this method, it uses Jack’s dummy driver and the libusb to communicate with the interface. Why did he not chose to write an Alsa quirk or a full module…

1 Like
#4

It directly bypasses ALSA and connects straight to JACK for optimal communication

mmm, isn’t it 100% contrary to the linux OS sound stack design ? ALSA is the official kernel space layer and provides a userspace layer as well for any sound server designer that wishes to interface with it. There had been other stuff like firewire (ffado) and whatnot, but nowadays, bypassing ALSA is just plain weird, especially for interacting exclusively with Jack.

I don’t own the target hardware, I just find it an odd design.

#5

I completely understand your points, and you are 100% right from an architectural perspective. Bypassing ALSA by bridging JACK’s dummy driver and libusb is definitely an unorthodox workaround rather than the “proper” Linux sound stack design.

The main reason for this approach was purely practical:

  • Maintainability & Stability: Writing an out-of-tree kernel module or ALSA quirk means dealing with constant DKMS maintenance, broken internal APIs, and rebuilding every time the kernel updates.
  • Rapid Prototyping: Reverse-engineering and debugging bulk transfer quirks is drastically faster and safer in userspace via libusb without the risk of kernel panics.

That said, having proper support merged upstream into ALSA (snd-usb-audio) would undeniably be the ideal, cleanest solution.

If anyone experienced with kernel/ALSA quirk development is willing to help port these findings upstream so it works out-of-the-box for everyone, that would be greatly appreciated and I’d be more than happy to share all the packet structures and protocol details.

#6

The Zoom product page says that UAC-8 works with iPad, which implies that it is USB audio class compliant. In almost all cases an interface which can work with iPad will work with no problems with the ALSA usb-snd driver.
Exactly what problems were you trying to solve?

#8

The assumption that “works with iPad = fully functional standard UAC2” is where this falls apart for the ZOOM UAC series.

Here is the actual technical reality of the hardware and the problem being solved:

  1. Isochronous vs. Bulk Transfers:
  • Standard USB Audio Class (and therefore the generic ALSA snd-usb-audio driver) relies on isochronous transfers. This is what runs in the iPad / Class Compliant mode.
  • However, ZOOM implements proprietary vendor-specific streaming via bulk transfers to achieve their advertised ultra-low latency and full channel counts under their native drivers. Standard snd-usb-audio does not handle this proprietary bulk transport.
  1. The ADAT Limitation in Class Compliant Mode:
  • When forced into standard Class Compliant / isochronous mode for iPad compatibility, the interface is severely crippled. Most critically, the ADAT optical I/O is completely disabled or fails to negotiate the full 18-in / 20-out channels.
  • To actually use the unit’s full hardware capabilities (full channel routing including ADAT at high sample rates), you cannot rely on generic snd-usb-audio.
  1. Why libusb + JACK Direct:
  • Instead of hacking an in-kernel ALSA driver to speak a non-standard vendor bulk protocol, it is handled directly in user space using libusb to claim the vendor endpoints.
  • That audio stream is fed straight into a custom JACK client/backend. ALSA is entirely bypassed here, which is why JACK is communicating with the hardware via user space USB without the ALSA stack.

So the problem being solved isn’t just “getting basic stereo sound on Linux”—it is recovering the missing ADAT channels and low-latency bulk transfer modes that standard ALSA simply cannot handle out of the box.

#9

I see. I found the manual and it does state that only the analog inputs and outputs are available in class compliant mode.
Given the device limitations your approach does seem like a reasonable approach to get access to the full features.

#10

Exactly. The next challenge is implementing a Linux equivalent of MixEfx to control the internal routing and onboard DSP (reverb/effects).

However, reverse-engineering all the vendor-specific control packets and USB HID/vendor requests is quite a tedious task. If anyone here has experience sniffing USB traffic or wants to help decipher the protocol, any help or collaboration would be greatly appreciated!

#11

I think you may find some inspiration, even help in that regard if you communicate with Geoffrey Bennett, who did the same for the Focusrite Scarlett soundcard series. You can contact him if you visit his github project alsa-scarlett-gui. He did end up making a kernel driver but also userspace stuff to support the full capabilities of the firmware (internal routing / mixing, etc).

1 Like
#12

Thanks a lot for the pointer, @djamo!

I’m actually familiar with Geoffrey Bennett’s incredible work on alsa-scarlett-gui. What he accomplished for the Scarlett Gen 2/3/4 series—decoding the proprietary mixing protocol and bridging it into both the kernel and a sleek userspace GUI—is practically the gold standard for what needs to be done here with the UAC-8.

While the UAC-8’s core audio streaming relies heavily on bulk endpoints rather than standard isochronous ALSA paths, the control protocol for internal routing, phantom power, and DSP (MixEfx) is likely handled via vendor/HID control transfers, which follows a very similar reverse-engineering workflow to what Geoffrey did.

I’ll definitely reach out to him or study his commit history and protocol documentation for inspiration on structuring the packet parser and control architecture.

In the meantime, if anyone has Wireshark/USBPcap logs from the official Zoom MixEfx app on Windows/macOS, feel free to share!