Arch Linux

carmik

Member

Registered: 2025-08-31

Posts: 26

[SOLVED] Pipewire on Xonar STX: only 48k rate supported?

(Cross-post from https://www.reddit.com/r/linuxaudio/com … ?context=1)

Basically title. I've got a Xonar STX under Arch Linux. The card supposedly supports all CD (44.k) and video (48k) standards and their multiples for both 16 an 24bit. According to the Arch wiki, I could include a conf file under ~/.config/pipewire/pipewire.d/ similar to this: https://wiki.archlinux.org/title/PipeWi … le_rate(s) in order to have bit perfect playback for 44.1kHz and 88.2k audio files.

According to https://www.alsa-project.org/wiki/Matrix:Vendor-Asus STX supports up to 192kHz@24bit hardware decoding. So it should work.

/etc/pipewire contains empty subdirectories, no system-wide pipewire configurations there. In my .config/pipewire there's only the pipewire.conf.d subdirectory, with 3 files as its contents. Two of them deal with the creation of a virtual 7.1 hesuvi device (works perfectly). The third file contains only the following:

$ cat .config/pipewire/pipewire.conf.d/05-samplerates.conf
context.properties = {
        default.clock.allowed-rates = [ 44100 88200 176400 48000 96000 192000 ]
}

No "general" pipewire.conf file exists in ~/.config/pipewire.

The issue: when running pw-top during 44.1kHz material from various music players, 48kHz is listed as the frequency. So it seems transcoding takes place, even though my pipewire config suggests 44.1 as a passable rate and the sound card shoule be 44.1 decoding capable. Any idea what I am missing here?

Some details of my config:

$ sudo dmesg |grep snd
[   12.064931] snd_virtuoso 0000:22:04.0: enabling device (0000 -> 0001)
[   12.070028] snd_hda_intel 0000:26:00.1: enabling device (0000 -> 0002)
[   12.070083] snd_hda_intel 0000:26:00.1: Disabling MSI
[   12.070091] snd_hda_intel 0000:26:00.1: Handle vga_switcheroo audio client
[   12.117386] usbcore: registered new interface driver snd-usb-audio

$ uname -a
Linux shocknawe 6.17.5-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 23 Oct 2025 18:49:03 +0000 x86_64 GNU/Linux

Right now I'm over SSH and I aplay -l does not show anything at all, however I can provide needed information when back at home

Last edited by carmik (2025-10-30 18:39:34)

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 24,866

Re: [SOLVED] Pipewire on Xonar STX: only 48k rate supported?

Which player(s) are you using and how sure are you they are not resampling themselves? Also a clock switch can only happen coming from "no usage", i.e. nothing should already be playing and the first 441kHz source you start should then open the device at that rate, everything playing back  afterwards needs to be mixed to that baseline, so if you have anything else that "starts" before you initiate playback that opens the device at 48000 that's what you'll be stuck with until the device is closed and can be reopened again. What happens if you playback with something simple, e.g. paplay or so?

Maybe share such a pw-top output? Did you see https://wiki.archlinux.org/title/PipeWi … le_rate(s) for veryfing what's supported on a kernel level?

Last edited by V1del (2025-10-30 12:20:25)

carmik

Member

Registered: 2025-08-31

Posts: 26

Re: [SOLVED] Pipewire on Xonar STX: only 48k rate supported?

I've tested after stopping/restarting wireplumber/pipewire/pipewire-pulse and indeed this time I saw 44.1khz files being sent just fine from mpv/fooyin etc! Please read below:

Which player(s) are you using and how sure are you they are not resampling themselves?

fooyin (a foobar 2000-type player), plus some other KDE-related apps (I've uninstalled them since, don't recall the names).

Also a clock switch can only happen coming from "no usage", i.e. nothing should already be playing and the first 441kHz source you start should then open the device at that rate, everything playing back  afterwards needs to be mixed to that baseline, so if you have anything else that "starts" before you initiate playback that opens the device at 48000 that's what you'll be stuck with until the device is closed and can be reopened again.

This blew my mind! I was under the (naive) impression that sources with different channel rates could be automagically combined: have a movie at 48kHz and an audio sample at 44.1, and have them play without neither one doing transcoding. So this is not the case, and most likely the reason all my testing failed.

My tests reproduced what you are saying: if I fresh start a 48khz playback everything is in 48k. If I stop this playback and switch to a 44.1 source, STX still receives at 48k.

So consider this thread solved, thank you for this piece of information!

Added info: I had had created a hesuvi style filter to change 7.1 source audio to binaural. And this seems to disallow the alsa device corresponding to the stx to going into a suspend state (as per pw-top). That's why it can not rate switch to another source with a different sampling rate! Disabling this device made (a) the device almost immediately be able to start a next source in another sampling rate. I've reached 192kHz playback without a hinch!

I'll try to find a way to disconnect this virtual device when not needed.

Did you see https://wiki.archlinux.org/title/PipeWi … le_rate(s) for veryfing what's supported on a kernel level?

I  was aware of those commands, however they did not produce any output in my case. This has something to do with the way my STX card is represented under /proc/asound. "grep -E 'Codec|Audio Output|rates' /proc/asound/card*/codec#*" produces no results (card0 is stx) since there are no codec files under proc/asound/card0. There are also no /proc/asound/card0/stream*files for the second command to work too.

Thanks again for your help!

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 24,866

Re: [SOLVED] Pipewire on Xonar STX: only 48k rate supported?

There "used to be" cards that had hardware mixers where this was possible (back in the days when it was absolutely necessary to have a dedicated sound card) in modern times and with modern cpus resampling is such a comparatively inexpensive operation that the majority of cards don't have  hardware mixers and are simply one single channel they open at one specific rate. pipewire then picks all your distinct playing applications and mixes them to one single stream.

An Asus STX might even be cabable of that, "aplay -l" could shed some light on whether this is possible, but the vast majority of sound cards in modern systems simply operate on that and expect the OS to do the mixing which will bring you into this limitation.