Re: [BUG] ALSA: usb-audio: Shanling UP4 (0a12:1244) silent at 44.1 kHz due to MaxPacketsOnly

[Takashi Iwai <tiwai@suse.de>]

On Fri, 02 Oct 2026 11:17:51 +0200,
Vadym S wrote:
> 
> 
> Hello,
> 
> The Shanling UP4 (Bluetooth DAC/amp with a USB DAC mode; CSR-based,
> USB ID 0a12:1244, UAC1, full speed, S16_LE, 44100/48000 Hz) outputs
> silence at 44.1 kHz on Linux, while 48 kHz works. On Windows the same
> unit plays fine with the default format set to 16 bit / 44100 Hz.
> 
> The cause appears to be the MaxPacketsOnly bit in the class-specific
> AS isochronous endpoint descriptor (bmAttributes 0x81). snd-usb-audio
> maps it to UAC_EP_CS_ATTR_FILL_MAX, so next_packet_size() always
> returns maxframesize: wMaxPacketSize 192 / 4 bytes = 48 frames per
> 1 ms packet, whatever rate is selected. At 44.1 kHz the device gets
> 48 frames per packet instead of the nominal 44/45 and plays nothing.
> 
> Measurement with plain ALSA (PipeWire not involved): a 4-second
> S16_LE stereo tone played with `aplay -D hw:UP4,0`, hw_ptr sampled
> from /proc/asound/UP4/pcm0p/sub0/status over 2 seconds:
> 
>   rate     hw_ptr advance    wall time for 4 s of audio
>   48000    47991 frames/s    4.01 s
>   44100    48030 frames/s    3.68 s
> 
> /proc/asound/UP4/stream0 while streaming at 44.1 kHz also shows the
> full packet size:
> 
>   Status: Running
>     Interface = 1
>     Altset = 1
>     Packet Size = 192
>     Momentary freq = 44100 Hz (0x2c.199a)
> 
> Listening tests (through PipeWire): 48 kHz is audible, 44.1 kHz is
> silent, reproducible. There are no errors in dmesg; setting the rate
> works (no "cannot set freq" messages).
> 
> This looks like the MOTU MicroBook IIc case (07fd:0004), which already
> clears FILL_MAX in snd_usb_audioformat_attributes_quirk(). Possibly
> related: the disabled Nura entry (0a12:1243) in quirks-table.h says
> "only the 48 kHz sample rate works for the playback interface" and
> sets FILL_MAX as well; that may be the same effect rather than a
> hardware limit. I can't verify this, I don't have that device.
> 
> As 0a12:xxxx IDs are CSR defaults that other products may share (cf.
> commit 5ebf6b1e4596, bugzilla 199905), note that the change below has
> no effect at 48 kHz: with wMaxPacketSize = 192 and 16-bit stereo,
> packsize[0] = packsize[1] = maxframesize = 48 frames, so the packets
> are identical with or without FILL_MAX. A device with the same ID that
> only works at 48 kHz would not be affected; only lower rates change.
> 
> Suggested change (untested on my side so far):
> 
> diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
> --- a/sound/usb/quirks.c
> +++ b/sound/usb/quirks.c
> @@ -2366,6 +2366,14 @@ void snd_usb_audioformat_attributes_quirk(struct
> snd_usb_audio *chip,
>   */
>   fp->attributes &= ~UAC_EP_CS_ATTR_FILL_MAX;
>   break;
> + case USB_ID(0x0a12, 0x1244):  /* Shanling UP4 */
> + /*
> + * MaxPacketsOnly is set, but the device expects nominal-size
> + * packets. Filling 48 frames per packet at 44.1 kHz results
> + * in silence. No effect at 48 kHz, where both sizes match.
> + */
> + fp->attributes &= ~UAC_EP_CS_ATTR_FILL_MAX;
> + break;
>   case USB_ID(0x1224, 0x2a25):  /* Jieli Technology USB PHY 2.0 */
>   /* mic works only when ep packet size is set to wMaxPacketSize */
>   fp->attributes |= UAC_EP_CS_ATTR_FILL_MAX;
> 
> Environment: Ubuntu 26.04, kernel 7.0.0-34-generic, PipeWire 1.6.2.
> Checked tiwai/sound.git for-next at b61a2369085f (2026-10-02): there
> is no entry for 0a12:1244 yet.

If the above change actually works for your device, it's fine to
apply.  Could you submit a proper patch for upstream?


thanks,

Takashi