There’s one thing that bothers me about this. Sure, PCM sampling is a lossless representation of the low frequency portions of a continuous signal. But it is not a latency-free representation. To recover a continuous signal covering the low frequencies (up to 20kHz) from PCM pulses at a sampling frequency f_s (f_s >= 40kHz), you turn each pulse into the appropriate kernel (sinc works and is ideal in a sense, but you probably want to low-pass filter the result as well), and that gives you the decoded signal. But it’s not causal! To recover the signal at time t, you need some pulses from times beyond t. If you’re using the sinc kernel, you need quite a lot of lookahead, because sinc decays very slowly and you don’t want to cut it off until it’s decayed enough.

So if you want to take a continuous (analog) signal, digitize it, then convert back to analog, you are fundamentally adding latency. And if you want to do DSP operations on a digital signal, you also generally add some latency. And the higher the sampling rate, the lower the latency you can achieve, because you can use more compact approximations of sinc that are still good enough below 20kHz.

None of this matters, at least in principle, for audio streaming over the Internet or for a stored library — there is a ton of latency, and up to a few ms extra is irrelevant as long as it’s managed correctly when at synchronizing different devices. But for live sound, or for a potentially long chain of DSP effects, I can easily imagine this making a difference, especially at 44.1ksps.

I don’t work in audio or DSP, and I haven’t extensively experimented. And I haven’t run the numbers. But I suspect that a couple passes of DSP effects or digitization at 44.1ksps may become audible to ordinary humans in terms of added latency if there are multiple different speakers with different effects or if A/V sync is carelessly involved.

Sampling does not lose information below the Nyquist limit, but quantization does introduce errors that can't be fixed. And resampling at a different rate might introduce extra errors, like when you recompress a JPEG.

    ```fish
    set -l sample ~/Music/your_sample_song.flac  # NOTE: Maybe clip a 30s sample beforehand
    set -l borked /tmp/borked.flac # WARN: Will get overwritten (but more likely won't exist yet)

    cp -f $sample $borked

    for i in (seq 10)
        echo "$i: Resampling to 44.1kHz..."
        ffmpeg -i $borked -ar 44100 -y $borked.tmp.flac 2>/dev/null
        mv $borked.tmp.flac $borked

        echo "$i: Resampling to 48kHz..."
        ffmpeg -i /tmp/borked.flac -ar 48000 -y $borked.tmp.flac 2>/dev/null
        mv $borked.tmp.flac $borked
    end

    echo "Playing original $sample"
    ffplay -nodisp -autoexit $sample 2>/dev/null
    echo "Playing borked file $borked"
    ffplay -nodisp -autoexit $borked 2>/dev/null

    echo "Diffing..."
    set -l spec_config 's=2048x1024:start=0:stop=22000:scale=log:legend=1'
    ffmpeg -i $sample -lavfi showspectrumpic=$spec_config /tmp/sample.png -y 2>/dev/null
    ffmpeg -i $borked -lavfi showspectrumpic=$spec_config /tmp/borked.png -y 2>/dev/null

    echo "Spectrograms,"
    ls -l /tmp/*.spec.png
    ```

The xiphmont link is pretty good. Reminded me of the nearly-useless (and growing more so every day) fact that incandescent bulbs not only make some noise, but the noise increases when the bulb is near end of life. I know this from working in an anechoic chamber lit by bare bulbs hanging by cords in the chamber. We would do calibration checks at the start of the day, and sometimes a recording of a silent chamber would be louder than normal and then we'd go in and shut the door and try to figure out which bulb was the loud one.

> All audio signal is _perfectly_ represented in a digital form.

That is not true... A 22kHz signal only has 2 data points for a sinusoidal waveform. Those 2 points could be anywhere I.e you could read 0 both times the waveform is sampled.... See Nyquist theorem.

From memory changing the sample rate can cause other issues with sample aliasing sue to the algorithms used...

This is a nice video. But I’m wondering: do we even need to get back the original signal from the samples? The zero-order hold output actually contains the same audible frequencies doesn’t it? If we only want to listen to it, the stepped wave would be enough then

Thanks for the links very interesting to read.

I buy loads of DJ music on Bandcamp and "downsample" (I think the term is) to 16bit if they only offer 24bit for smaller size and wider compatability.

> All audio signal is _perfectly_ represented in a digital form

What? No. All bandwidth limited signal is. Which means periodic. Causal signals like audio can be approximated, with tradeoffs. Such as pre-ringing (look at sinc(x), used to reconstruct sampled signal — how much energy is in the limb preceding the x=0.)

Is the approximation achieved by filtering the 44.1kHz DAC good enough? Yes, yes it is. But the math is way more involved (i.e. beyond me) than simply "Niquist".

This popular myth that limited frequencies we can hear and limited frequencies in Fourier transform sense is the same thing is quite irritating.

in theory yes, in practice no.

the article explains why.

tldr: formula for regenerating signal at time t uses an infinite amount of samples in the past and future.

The short answer is that our eyes and ears use very different processing mechanisms. Our eyes sense using rods and cones where the distribution of them reflects a spatial distribution of the image. Our ears instead work by performing an analogue forier transform and hearing the frequencies. If you take an image and add lots of very high frequency noise, the result will be almost indistinguishable, but if you do the same for audio it will sound like a complete mess.

AFAIK it introduces harmonic distortion

That seems a rather shallow - and probably incorrect - reading of the source. This is an efficiency and trust trade off as noted:

> given sufficient computing resources, we can resample 44.1 kHz to 48 kHz perfectly. No loss, no inaccuracies.

and then further

> Your smartphone probably can resample 44.1 kHz to 48 kHz in such a way that the errors are undetectable even in theory, because they are smaller than the noise floor. Proper audio equipment can certainly do so.

That is you don't need the original source to do a proper transfer. The author is simply noting

> Although this conversion can be done in such a way as to produce no audible errors, it's hard to be sure it actually is.

That is that re-sampling is not a bad idea in this case because it's going to have any sort of error if done properly, it's just that the Author notes you cannot trust any random given re-sampler to do so.

Therefore if you do need to resample, you can do so without the analog source, as long as you have a re-sampler you can trust, or do it yourself.

If only it was that simple T_T

I'm working on a game. My game stores audio files as 44.1kHz .ogg files. If my game is the only thing playing audio, then great, the system sound mixer can configure the DAC to work in 44.1kHz mode.

But if other software is trying to play 48kHz sound files at the same time? Either my game has to resample from 44.1kHz to 48kHz before sending it to the system, or the system sound mixer needs to resample it to 48kHz, or the system sound mixer needs to resample the other software from 48kHz to 44.1kHz.

Unless I'm missing something?

If 44.1kHz is otherwise sufficient but you have a downstream workflow that is incompatible, there are arguments for doing this. It can be done with no loss in quality.

From an information theory perspective, this is like putting a smaller pipe right through the middle of a bigger one. The channel capacity is the only variable that is changing and we are increasing it.

A very common clear need is incorporating 44.1khz audio sourcesinto video. 48khz is 48khz because 48khz divided by 24fps, 25fps, or 30fps is an integer (and 44.1khz is not).

Also, for decades upsampling on ingest and downsampling on egress has been standard practice for DSP because it reduces audible artifacts from truncation and other rounding techniques.

Finally, most recorded sound does not have an original analog source because of the access digital recording has created…youtube for example.

> I wonder if this problem could be "solved" by having some kind of "dual mode" DACs that can accept two streams of audio at different sample rates, likely 44.1khz and 48khz, which are converted to analog in parallel and then mixed back together at the analog output.

You'd just resample both at 192kHz and run it into 192kHz DAC. The "headroom" means you don't need to use the very CPU intensive "perfect" resample.

Sinc interpolation is somewhat resource-intensive / latency inducing which is why it's not used as frequently in realtime audio.

I had a Soundblaster Live! Gold card back in the day, and I would route my record player or stereo through it so I could use a visualizer on my computer. You could hear the digital noise that was introduced on the highhats. And the source for the sound was a late '70s era Realistic system where everything was analogue. I never knew it was because of the soundcard. I'd always just chalked it up to either Windows XP or VLC doing something.