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
(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.