[BUG] Mackie DLZ Creator XS – USB Audio: write error -77 after accepted hw_params

[BUG] Mackie DLZ Creator XS – USB Audio: write error -77 after accepted hw_params

[Brian Knutsson]

Hi ALSA devs,

I'm reporting an issue with the Mackie DLZ Creator XS USB audio device on Linux (tested on Ubuntu 24.04 and 25.05 with kernel 6.8+).

The device is detected correctly via ALSA (card 2: XS), but as soon as playback is initiated – whether via `aplay` or `speaker-test` – it disconnects with `write error: -77, File descriptor in bad state`.

Relevant kernel logs show:
usb 3-7: Product: DLZ Creator XS
usb 3-7: Manufacturer: LOUD Audio, LLC
usb 3-7: USB disconnect, device number X

This occurs with and without PipeWire/udev running.

I’ve created a full ALSA log with `alsa-info` and opened a Kernel Bugzilla entry: <https://bugzilla.kernel.org/show_bug.cgi?id=220143>

Is there any known quirk or patch needed for this hardware? Or a way to assist debugging further (usbmon trace etc.)?

Thanks in advance,
Brian Knutsson

Re: [BUG] Mackie DLZ Creator XS – USB Audio: write error -77 after accepted hw_params

[Geraldo Nascimento]

On Fri, Jun 27, 2025 at 03:26:17PM +0200, Brian Knutsson wrote:
> 
> Hi ALSA devs,
> 
> I'm reporting an issue with the Mackie DLZ Creator XS USB audio device on Linux (tested on Ubuntu 24.04 and 25.05 with kernel 6.8+).
> 
> The device is detected correctly via ALSA (card 2: XS), but as soon as playback is initiated – whether via `aplay` or `speaker-test` – it disconnects with `write error: -77, File descriptor in bad state`.
> 
> Relevant kernel logs show:
> usb 3-7: Product: DLZ Creator XS
> usb 3-7: Manufacturer: LOUD Audio, LLC
> usb 3-7: USB disconnect, device number X
> 
> This occurs with and without PipeWire/udev running.
> 
> I’ve created a full ALSA log with `alsa-info` and opened a Kernel Bugzilla entry: <https://bugzilla.kernel.org/show_bug.cgi?id=220143>
> 
> Is there any known quirk or patch needed for this hardware? Or a way to assist debugging further (usbmon trace etc.)?

Hi Brian, thank you for the report.

Has this device worked before on previous kernels? If yes, you can try
to find which kernel version was first affected and then run run `git
bisect` between non-affected and affected versions to try to pinpoint
offending commit.

If the answer however is no, then you're pretty much on your own and
it's up to you to compare working Windows usb traces with Linux ones.
I suggest you try existing quirks first to see if one of them handles
your bug, but if none does, then it's like I said, pretty much manual
development.

Thanks,
Geraldo Nascimento

> 
> Thanks in advance,
> Brian Knutsson