Skip to content

Instantly share code, notes, and snippets.

@nikreiman
Last active August 30, 2018 18:28
Show Gist options
  • Star 3 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save nikreiman/5009156 to your computer and use it in GitHub Desktop.
Save nikreiman/5009156 to your computer and use it in GitHub Desktop.
Why have a sample rate as a floating point number?
Why have a sample rate as a floating point number?
Many audio API's, such as the VST and CoreAudio SDK's, represent the sampling
rate of the audio hardware as a floating point number. This may seem rather
silly at first, given that it's impossible to have a sample rate of 44100.5.
Thus it would seem that an unsigned integer (ie, uint32_t), would be an ideal
container for sample rate.
However, there is a reason that many audio API's use float (or better yet,
double) for sample rate. The reason is because that most DSP algorithms rely on
processing floating point data, that is, samples in the range {-1.0 .. 1.0}.
Although this can be represented in 16-bit audio as {-32676 .. 32767}, it's much
easier to do most DSP math stuff with floating point numbers. And this is
exactly why when working with audio plugins you are given an array of floating
point numbers to process.
So, back to the sampling rate. If you are writing a stream-based audio plugin
(such as a synthesizer), you rely on the sampling rate for many things, such as
calculating the period or any number of other things. It's a fundamental unit
for many DSP algorithms, and for that reason, it's much more convenient to have
it as a floating point number.
That said, it's not very difficult to cast the sample rate to floating point,
but forgetting to do so will often result in weird behavior from an application
using integer truncation. Plus, it's annoying to do this all the time or to
store a copy of it as a float. For this reason, it's a "common courtesy" among
audio frameworks to provide the sampling rate as a floating point number,
because the assumption is that even though it *is* an integer, it's not much use
in calculations as an integer data type.
@basdirks
Copy link

basdirks commented Feb 1, 2015

I was wondering this too. I also choose pragmatism over correctness in this case.

@ssfrr
Copy link

ssfrr commented Apr 4, 2018

why would it be impossible to have a sample rate of 44100.5? I mean, most real-world audio hardware only supports a small number of fixed sampling rates that happen to be integers, but there's nothing to say that your internal processing, or some more esoteric hardware, wouldn't be running at some non-integer sampling rate.

@tvoeroes
Copy link

It is perfectly possible to have a sampling rate that is not an integer. It just happens to be an uncommon thing in digital audio.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment