On 10/14/22 05:21, Alexandre Ratchov wrote:
On Thu, Oct 13, 2022 at 05:20:49PM -0400, Geoff Steckel wrote:
If those don't work it's a (fixable) bug/not-yet-implemented.
I've tried those settings with ambiguous results but not failure.
My usb dacs don't have visible indicators & I don't have a
USB protocol sniffer.
Running audioctl during playback reveals the device sample rate.
Running audioctl shows what the system thinks the device rate is.
In my experience resampling quality in any particular implementation
is not guaranteed and can introduce significant artifacts.
Declaring a particular implementation "good enough" without
knowing more seems premature.
Here are the measures of the aliasing noise using sine sweeps. Check
the figure for the 44.1kHz to 48kH conversion, the sndiod column:
https://arverb.com/pub/src/
I did simple A/B tests with music from CDs and my ears couldn't hear
the aliasing noise. Try it.
Good a/b >x< tests for audio require extreme care to get accurate results.
Simple sine sweeps don't show IM distortion well.
In most cases numerically equal amounts of IM distortion are far more easily
noticed than harmonic distortions or simple noise (white, pink, etc.)
Sometimes you just don't want to think about it (ex., when you debug
audio stuff), so resampling off-line (or switching the device rate)
still makes sense in certain cases.
This is the classic "why would you ever want to do that?"
"Just as good" is an opinion.
Other OSs can and do provide controls which allow setting the device
sample rate to whatever the device can do.
This user wants that to work.
This means compiling a kernel with AUDIO_DEBUG Real Soon Now
and inserting a few more DPRINTFs.
