-
Notifications
You must be signed in to change notification settings - Fork 237
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't play 44100hz, 88200hz files Natively. #313
Comments
Which hardware are you using? |
Sorry, I should have mentioned it earlier. Realtek 4080 on the MSI b650 Mortar Wi-Fi board. |
There is no forced rate or resamling specificed in the configuration file for this hw - https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/USB-Audio/Realtek/ALC4080-HiFi.conf . We had some issues in the USB driver (rate lock when the first device is opened for the given USB sound card), but they should be fixed in the latest kernels. Maybe there's something left. Does "Pro Audio" open only the playback device ? You may check this in procfs - @tiwai : FYI... |
Thanks, I am on 6.1.26-1-MANJARO. I'm not too sure what you mean, but please see below for cat /proc/asound/card*/pcm*/sub0/* when Pro Audio is selected under pavucontrol.
|
I see 44100Hz in both outputs. You can filter the output only for the problematic card - use |
I see 44100 as well, but my DAC displays the current sample rate and selecting Hifi 2.0 puts out only 48000hz to the DAC. |
It's weird, but it looks like an issue somewhere else (maybe the USB card does some hidden resampling?). The alsa-lib/ucm does not hardcode the rate for this device. The procfs values are from the driver, so the user space sets the rate correctly. |
This is a built in motherboard solution. If switching to pro audio fixes issue, I don’t think it’s a hardware thing. Could it be that in the driver somewhere it thinks the Realtek 4080 can’t do 44100hz? |
If the 44100Hz is in procfs then the user space already sets to this rate and the driver should issue the USB rate command to the hardware with this settings. You may check the rate settings sent through USB using the dynamic debug for the
Look to dmesg for the debug lines.. |
My previous OS was a clean install of the latest Manjaro build and this issue was present. I now have a clean install of Ubuntu and 23.04 and the issue persists here as well. The pro audio work around does not work with this OS. Sorry, I don't know what you mean to do with: echo "options snd-usb-audio dyndbg=+p" > /etc/modprobe.d/alsa-test.conf and reboot ...Should I just cut and paste that in my terminal? |
Hi @perexg, I am having the same problem. I'm creating UCM2 profiles for the Focusrite USB interfaces. They support:
When I use my UCM2 profile that splits the inputs and outputs up, PipeWire will only select 48kHz. The Pro Audio and Direct profiles can use all the sample rates. So I'm guessing it's an issue with what UCM2 advertises to PipeWire, or an issue with how PipeWire interprets what it reads from UCM2? Switching profiles from Pro Audio to my "Default" UCM2 profile when playing audio at 192kHz, I see lots of these:
There's about 30 of those Start Capture PCM, Stop Capture PCM, Start Playback PCM, Stop Playback PCM on usb interface 1:1 and 2:1 continuing over about 10 secs until audio resumes (at 48kHz). Then:
And I see:
I'm not sure where to look from here? Thanks, |
Sorry, I should have mentioned: Fedora 38 and:
|
@geoffreybennett This bug is for ALC4080. For configurations using split macros, the default rate is hardcoded to 48kHz in the alsa-lib direct plugins. It would be better to create a bug in alsa-lib issue tracker. |
Can't play audio files at native sample rate. Everything using the Hifi 2.0 output configuration forces a sample rate of 48000hz. When I switch to the Pro Audio driver under pavucontrol, 44100 hz can play natively. Is there a forced resampling occuring in the UCM2 driver?
The text was updated successfully, but these errors were encountered: