Mackie DLZ Creator XS on Linux

The DLZ Creator XS (0a73:003a) works on Windows, macOS and iOS but falls off the USB bus on Linux, usually within a couple of seconds of playing or recording anything. dmesg shows a disconnect, and applications report No such device or write error -77 on a device that enumerated perfectly a moment earlier.

There are two separate problems. One is a Linux bug with a kernel fix; the other is a firmware requirement you work around in userspace.

Is this you?

$ dmesg | tail
usb 3-1.1.2: USB disconnect, device number 122
$ arecord -D hw:XS,0 -f S32_LE -c 14 -r 48000 test.wav
arecord: main:850: audio open error: No such device

Streams start correctly, audio is byte-correct, and then the device vanishes and re-enumerates with a new device number. Nothing in the logs blames the driver.

Problem 1 — the device drops off the bus

set_sample_rate_v2v3() skips the SET_CUR write when the clock already reports the requested rate. This device advertises exactly one rate (48 kHz), so that branch is always taken and it never receives the write — which it requires. Windows and iOS issue it unconditionally on every stream start.

Fixed by QUIRK_FLAG_ALWAYS_SET_RATE, applied 2026-08-09 to tiwai/sound.git for-next as 786f91da85, so it reaches mainline in the next merge window. See patches/0002-* and docs/investigation.md.

Until it reaches your kernel, pick one:

• The zero-effort fix. Plug the DLZ into an iPhone, iPad, Mac or Windows machine and play a few seconds of audio. The unit is self-powered, so the armed state survives being unplugged, and Linux will drive it correctly until the next time it loses mains power. Repeat after every power cycle.
• Build the patched module. See Building.

Once your kernel carries the quirk, neither is needed. If you are not sure whether it does, just try the device from cold: if it survives more than a few seconds of playback without having been initialized elsewhere, you have it.

Problem 2 — recording alone kills it

A playback stream must be running whenever the capture endpoint is active.

This one is not a kernel bug and no kernel release will fix it. The device drops off the bus at a fixed 0.750 s if its capture endpoint runs with no outgoing packets in flight — measured, and independent of USB interface state or the order streams are opened. Windows, macOS and iOS all keep a playback stream open for the entire session, so they never reach the deadline; ALSA and PipeWire are alone in letting you open the microphone without the speaker.

The fix is to stop PipeWire from ever suspending the device, so an outgoing stream is always live before anything can open the source.

cp config/50-dlz-creator.conf ~/.config/wireplumber/wireplumber.conf.d/
systemctl --user restart wireplumber

Nodes still start suspended after a reboot, so also open the sink once at login:

install -Dm755 config/dlz-keepalive.sh ~/.local/bin/dlz-keepalive.sh
cp config/dlz-keepalive.service ~/.config/systemd/user/
systemctl --user enable --now dlz-keepalive.service

That plays one second of silence into the device. It finds the sink itself by matching the USB product string, so there is nothing to edit, and it feeds pw-cat zeros straight from /dev/zero rather than needing an audio file. It exits quietly if the device is not attached.

Check it works with systemctl --user status dlz-keepalive.service — it prints the sink it opened.

Hot-plug caveat: if you attach the DLZ mid-session, play something once before recording. The service only runs at login.

Verified working

pw-record --target <dlz-source> --channels 14 --rate 48000 out.wav
→ 29.93 s, 14 ch, 48 kHz, 0 disconnects

Building the patched module

Only needed until the quirk reaches your kernel. Apply patches/0002-* to the sound/usb directory of a kernel tree matching your running kernel, build it out of tree, then:

sudo rmmod snd_usb_audio
sudo insmod /path/to/snd-usb-audio.ko

You need kernel headers for the running kernel, and the same compiler it was built with — check cat /proc/version, since a clang-built kernel (Arch, CachyOS) needs LLVM=1.

The scripts in scripts/ take the module path from $DLZ_KO.

What is here

config/	the WirePlumber and systemd units for Problem 2
patches/	the kernel patch as applied upstream, plus one held back
docs/	how the bug was found, and every hypothesis that turned out wrong
scripts/	reproduction and measurement scripts
traces/	USB captures from Windows and Linux, and the analysis tools

Reporting

If you have this device, a second confirmation upstream is genuinely useful — so far the evidence comes from a single unit. The existing reports are alsa-devel, June 2025 and Bugzilla 220143.

AI assistance

Parts of this work — patches, scripts and documentation — were written with the help of an AI coding assistant (Claude Code). Every claim here was verified against traces from the actual hardware, and several plausible explanations it proposed were disproven by measurement; those are recorded in docs/investigation.md rather than quietly dropped.

License

GPL-2.0, matching the kernel the patches derive from. See LICENSE.