mirror of
https://github.com/torvalds/linux.git
synced 2026-11-06 21:58:01 +01:00
d842c03f89
The NUX NAI-24 (USB 3703:2000) has a UAC2 clock source that reports bmAttributes = 0x01 (internal fixed clock) and bmControls = 0x07, so the driver treats its sample rate as programmable. When the driver sends SET_CUR(SAMPLING_FREQ_CONTROL), the firmware acknowledges the request and then runs the clock on the opposite base-rate family: asking for 44100 Hz makes the device run at 48000 Hz, and asking for 48000 Hz makes it run at 44100 Hz. The result is playback that is about 8.8% fast, or 8.4% slow with heavy static on the 48000 Hz family. macOS and Windows ignore bmControls, treat the clock as fixed and resample, so they are unaffected. Work around it by sending the partner rate in SET_CUR for this device, so the device runs at the requested rate. A new QUIRK_FLAG_SWAP_RATES flag controls this, applied through the quirk flags table. Only the 44.1/48 kHz pair has been verified on hardware; the 88.2/96 kHz and 176.4/192 kHz pairs are untested but follow the same pattern. Testing: the equivalent change ran on the device as a locally built module (44100 Hz PCM, device clock 44100 Hz, no xruns, correct tempo, no static). This upstream form compiles for sound/usb without warnings and passes checkpatch, but has not been built in a full kernel tree or load-tested. Assisted-by: LLM Signed-off-by: Darren Chang <darrenchangjr01@gmail.com> Link: https://patch.msgid.link/20260920122653.41993-1-darrenchangjr01@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> |
||
|---|---|---|
| .. | ||
| cards | ||
| codecs | ||
| designs | ||
| hd-audio | ||
| kernel-api | ||
| soc | ||
| alsa-configuration.rst | ||
| index.rst | ||
| utimers.rst | ||