Bug 217501
| Summary: | Apple USB-C 3.5mm dongle cannot output 41000hz | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | AT (kernel) |
| Component: | Sound(ALSA) | Assignee: | Jaroslav Kysela (perex) |
| Status: | NEEDINFO --- | ||
| Severity: | normal | CC: | bagasdotme, ishitatsuyuki, tiwai |
| Priority: | P3 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | Subsystem: | ||
| Regression: | No | Bisected commit-id: | |
| Attachments: |
alsa-info.sh
lspci lsmod usb descriptor info of Apple USB-C dongle |
||
|
Description
AT
2023-05-29 06:25:48 UTC
(In reply to AT from comment #0) > Overview: > With an A2049 Apple USB-C to 3.5mm DAC dongle, I have the same issue as > outlined in this link: ALSA won't detect 44100Hz as an available sample rate: > https://github.com/mikebrady/shairport-sync/issues/1504 > > > Steps to Reproduce: > Play a 44.1Khz audio file. > > > Actual Results: > Pipewire reports that the output is locked to 48000hz, and ALSA reports that > this is the only detected supported rate: > > $ cat /proc/asound/card0/stream0 > Playback: > Status: Running > Interface = 1 > Altset = 1 > Packet Size = 288 > Momentary freq = 48000 Hz (0x30.0000) > Interface 1 > Altset 1 > Format: S24_3LE > Channels: 2 > Endpoint: 0x02 (2 OUT) (SYNC) > Rates: 48000 - 48000 (continuous) > Bits: 0 > Channel map: FL FR > Interface 1 > Altset 2 > Format: S16_LE > Channels: 2 > Endpoint: 0x02 (2 OUT) (SYNC) > Rates: 48000 - 48000 (continuous) > Bits: 0 > Channel map: FL FR > > > Expected Result: > It should be switching between 44100-48000hz, the only two rates it supports. > > > Build Date and Hardware: > Running Arch Linux with kernel 6.3.4-arch1-1, alsa-lib 1.2.9-1. > AMD Ryzen 3600 on a MSI B450M Mortar Max motherboard > > > Additional Information: > It seems like a regression between Linux 4.x and 5.x, and halfway through > the above thread the user "quantonian" added the device to the ALSA quirks > table and has posted a patch: > > https://github.com/mikebrady/shairport-sync/issues/1504#issuecomment- > 1193355701 > > Thanks if this can be fixed in the kernel. The dongle in question is US $9: > https://www.apple.com/shop/product/MU7E2AM/A/usb-c-to-35-mm-headphone-jack- > adapter lspci? lsmod? Created attachment 304346 [details]
alsa-info.sh
Created attachment 304347 [details]
lspci
Created attachment 304348 [details]
lsmod
Have attached those along with the output of the alsa-info.sh script which includes USB info. Here's some further notes linked from within the Github issue, same 48000-48000 rates reported with Raspbian kernel 5.10 but 44100,48000 reported with kernel 4.19: https://www.audiosciencereview.com/forum/index.php?threads/review-apple-vs-google-usb-c-headphone-adapters.5541/page-32 Can you perform bisection between v4.9 and v5.10? (In reply to Bagas Sanjaya from comment #6) > Can you perform bisection between v4.9 and v5.10? I have an old kernel 5.6.0 built from AMDGPU drm-next (out of necessity when I assembled this computer), and it still has the same issue with rates 48000-48000. Sorry, can't go much further back without GPU crashing/unsupported. Could you try the older kernel (at best git bisect) without native graphics? Only for debugging the USB-audio, we don't need the proper graphics, but EFI framebuffer should suffice. Looking at the commit log, a reasonable guess is BADD support [1]. The spec literally says: All BADD AudioStreaming interfaces shall only support 48 kHz. They shall support both 16 bits and 24 bits sample sizes. though, not sure if that implies a capability downgrade from previous versions. [1]: https://github.com/torvalds/linux/commit/17156f23e93c0f59e06dd2aaffd06221341caaee Created attachment 304396 [details]
usb descriptor info of Apple USB-C dongle
It seems we're indeed selecting the BADD config when another UAC3 config exists.
In the attached descriptor info, BADD is bConfigurationValue=2, while bConfigurationValue=3 has more advanced control over clocks and others.
The current logic selects the *first* UAC3 config, see [1]. [1]: https://github.com/torvalds/linux/blob/022ce8862dff83c859089cd14bc4dca0733e2f90/drivers/usb/core/generic.c#L121-L144 (In reply to Takashi Iwai from comment #8) > Could you try the older kernel (at best git bisect) without native graphics? > Only for debugging the USB-audio, we don't need the proper graphics, but EFI > framebuffer should suffice. Sorry will be heading away from home for the next few weeks, but it sounds like progress is being made with your BADD/UAC3 suggestion, thanks! (In reply to Tatsuyuki Ishi from comment #9) > Looking at the commit log, a reasonable guess is BADD support [1]. Yes, it would explain the behavior. But the puzzling part is that I don't remember any changes related with BADD profile selection in the recent changes. Maybe the "regression" meant here was so old (about 2018/2019), the introduction of BADD profile support in 4.18 kernel. |