Hi Maxim,
Maxim Cournoyer <[email protected]> writes:
Ian Eure <[email protected]> writes:
It looks like newish PW lets you give a preference list of
samplerates; these PW docs may be helpful to you:
https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Guide-Rates
and
https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Config-PipeWire#setting-sample-rates
Thanks for the links, they helped. So setting
default.clock.rate will
change the rate globally, while setting the allow-rates will let
PipeWire use these rates to match a source when, and that is not
explained much around, there is no mixing going on (single
application
outputting audio). If many streams need to be mixed then it
falls back
to use default.clock.rate.
Gotcha, I was wondering if it was something along those lines.
Glad you got this figured out.
I assume you already know for certain that your audio device
supports
the samplerates you’re asking for? `guix shell tree alsa-utils
--
alsa-info.sh --no-upload --stdout --with-devices' will print
pages of
stuff including the supported samplerates.
Yes, my motherboard has some ALC4080 chip which supports up to
384 kHz,
while the hi-fi amplifier has a sampling rate of up to 192 kHz
on its
optical (toslink/SPDIF) input. I've found out that for some
reason
there is some crackling when pushing it all the way to 192 kHz;
I'm not
sure if the onboard audio SPDIF port (it does not happen when
using the
analog output) or the amplifier DAC is to blame, but dialing it
down to
96 kHz gives a clean signal.
Interesting. I’ve had some kind of similar issues with my setup,
but it was due to running on a raspi. I have a USB DAC, and there
seems to be some kind of bus contention between the USB and WiFi
(all my music is on a NFS share the Pi mounts) which causes buffer
underruns at high sample rates. It manifested as light crackling
to the music completely stopping. Problem went away when I moved
it to a more powerful machine with PCIe WiFi.
Maybe something similar is happening with your setup?
-- Ian
