resample-method = soxr-vhq ; was speex-float-1 → speex-float-10 → soxr-vhq (if supported)
default-sample-format = float32ne ; was s16le precision
default-sample-rate = 96000 ; was 44100 → 48000
alternate-sample-rate = 88200 ; was 48000 → 44100
default-sample-channels = 8 ; was 2 → 6 → 8
(yes i can’t hear up to 96/2kHz but in case of imperfect sampling and
one of my hardware outputs have limited bit=depth, guess do audio super-sampling to compensate for that somewhat)
humans can hear up to 20 kHz thus sample rates much more than double that (nyquist)
(but due to better resampling, 48kHz is better than 44.1kHz)
but since i sometimes use HDMI audio output in addition to main output,
my computer only supports 16-bits output for that, but up to 96kHz
(oversimplified) it might effectively behave like (16+1)-bits (96/2)kHz audio
Increased sample rate and increased bit-depth achieve different things.
Increasing the sample rate increases the available bandwidth (as you say, the higher the sample rate, the higher the Nyquist frequency). Sample rate has no affect on the available dynamic range.
Increasing the bit-depth increases the available dynamic range (for integer formats, the quantization noise floor goes down by approximately 6 dB per bit). Bit-depth has no affect on the available bandwidth.
Though with high quality resampling, it is highly unlikely that the difference will be enough to be audibly different. On the other hand, a sound card may just work better at one sample rate than another - it’s not uncommon for audio devices to produce worse sound quality when set at their maximum sample rate.
got the sound → decent after settings the project sample rate to 96kHz
does audacity output to alsa directly instead of via pulseaudio can it detect the current sample rate the the hardware is currently using and use that?
if i set project sample rate to 192kHz
i get same thing: abnormally fast-forward scratchy barely-recognizable (corrupted) audio
another reason for using oversampled audio for pulseaudio:
since it mixes audio from multiple apps, and hardware uses integer output eventually,
there is a risk of clipping if more than one app is outputting audio,
see Oversampled Clipping Demo
various audio chirps, and the effect that oversampling has on clipping
That depends on the settings in the Device Toolbar (Device Toolbar - Audacity Manual)
When “host” is set to “ALSA” and the devices are set to either “default” or “Pulse”, then PulseAudio is used.
When “host” is set to “ALSA” and the devices are set to “hw” options, then Audacity bypasses PulseAudio and goes straight to the ALSA device.
No, you have to set that yourself. As far as I’m aware, there’s no way for a program to determine the sample rate that the hardware is using.
Audacity tries to ensure that it sends audio data at a sample rate that is supported by the device, though not all device drivers report their supported sample rates correctly.
You should set your levels appropriately to avoid clipping. Clipped audio generally sounds bad (other than intentional distortion as an effect) regardless of whether there is anti-aliasing or not.
“Oversampling” is not the same thing as “using a high sample rate”.
does audacity output to alsa directly instead of via pulseaudio