Ozzy: A Kernel-Level Second Life for Ploytec-Based Allen & Heath Mixers

The Problem: Vendor Abandonment of Professional USB Audio

Professional USB audio hardware often does not follow the USB Audio Class specification. These non-class compliant devices require vendor-specific drivers to handle custom routing, DSP control, and low-latency protocols. When a manufacturer stops updating those drivers, the hardware stops working on newer operating systems. Ozzy targets exactly this situation. It is for owners of Allen & Heath Xone mixers who have working hardware but no working driver on modern macOS or Linux. The README is blunt about the scope: it supports the Xone:DB4, DB2, DX, and 4D, all using the Ploytec-based protocol. If your device is not on that list, Ozzy does not help you yet.

Reverse Engineering as a Maintenance Strategy

Ozzy is not a wrapper around an existing driver. It is a reverse-engineered implementation of the vendor protocol. The README states that the architecture separates the audio engine from device protocols, which means adding a new device is a matter of implementing its protocol rather than rewriting the entire driver. This is a pragmatic approach for hardware that has no official support. The reverse engineering effort is the core value here. Without it, the mixers are e-waste. With it, they gain a modern driver. The trade-off is that the driver only works as well as the reverse engineering is accurate. The README marks all four devices as 'Perfect' in status, but that is a claim from the project, not an independent verification.

Kernel-Mode Design: Why It Matters

Ozzy uses kernel-mode drivers on both macOS and Linux. The README explains that non-class compliant devices need direct USB pipe access and precise timing that only kernel space can provide. On macOS, the current implementation is a kernel extension (kext) with three backend options listed: the kext is fully implemented, a DriverKit extension is in development, and a userspace daemon is planned. The kext requires SIP to be modified with `csrutil enable --without kext`. That is a significant security concession. The Linux side is a standard ALSA kernel module with automatic BULK/INTERRUPT transfer detection. The kernel-mode choice gives low latency, but it also raises the barrier to entry. Users must be comfortable with system-level changes and potential security implications.

Getting It Running: Commands and Certificates

Installation differs by platform. On Linux, the README gives a clear path: clone the repository, run `make` and `sudo make install` in the `linux/` directory, then load the module with `sudo modprobe snd-usb-ozzy`. On macOS, the install script is `./install.command` in the `macos/` directory. That script checks SIP configuration, compiles the kext, builds the HAL and MIDI drivers, installs them, and configures auto-loading. Uninstall is `macos/uninstall.command`, and troubleshooting uses `macos/debuglogs.command`. The macOS build requires code signing. The README spends considerable time on the '0 valid identities found' error, which is a common failure. The fix involves adding a free Apple ID in Xcode, creating an Apple Development certificate, and ensuring Keychain Access does not have a custom trust policy. This is a real friction point, not a trivial install.

Platform Support: macOS Is Ready, Linux Is Simpler, Windows Is Not

The README states macOS support is fully implemented and stable, with 8x8 audio via CoreAudio HAL and full CoreMIDI support using lock-free ring buffers. Linux support is described as a standard ALSA kernel module that integrates with JACK, PulseAudio, and PipeWire. Windows is listed as 'Coming soon' with a WASAPI kernel-mode driver in development. For a project that aims to revive abandoned hardware, the lack of Windows support is a notable gap. Many professional DJs and producers use Windows. The macOS kext path also has a limited future: Apple has been deprecating kexts in favor of DriverKit. The README acknowledges this with a planned DriverKit extension, but it is not ready. If you are on Windows or want a future-proof macOS solution, Ozzy is not there yet.

The Code-Signing Pain: A Real Cost of Adoption

The README goes into unusual detail about the code-signing process, which suggests it is the biggest practical hurdle. The '0 valid identities found' error is attributed to Apple's certificate chain issues, including an expired WWDR G1 intermediate certificate that broke codesigning for many developers. The README also warns about a Keychain Access trap where setting 'Always Trust' on a certificate can silently break `security find-identity`. These are not Ozzy bugs, but they are part of the adoption cost. A user who is not familiar with Apple's certificate management could spend hours on this. The README provides a diagnostic checklist, but it does not automate the fix. This is a maintenance burden that a user must accept when choosing Ozzy over a commercial driver, if one existed.

Licence and Maintenance Considerations

Ozzy is MIT-licensed, which is permissive and allows commercial use, modification, and redistribution with attribution. That is a positive for adoption. The repository shows no recent releases and the last push is unknown, which is a concern for maintenance. The README describes the project as actively developed, with a DriverKit backend in progress, but there is no release history to confirm a stable cadence. The Linux module is built from source, so users must be prepared to recompile after kernel updates. The macOS kext also depends on the system's SIP state, which can change with OS updates. The project's future depends on the maintainer's continued effort, and the README's roadmap is the only evidence of that. Before adopting, check the repository's commit history and issue tracker for signs of activity.

Editorial conclusion

Adopt Ozzy if you own a supported Allen & Heath Xone mixer, run macOS 11+ or Linux, and are willing to modify SIP or build a kernel module. Do not adopt it if you need Windows support (still in development) or if you expect a plug-and-play userspace solution. Before relying on it, verify your exact device model against the supported list, check your macOS SIP configuration, and confirm you have a valid Apple code-signing identity, as the build process depends on it. The project is MIT-licensed, but the macOS kext path requires a security trade-off that you should accept only if the hardware's value justifies it.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases