> This clock is exposed on the AudioContext object through its .currentTime property, as a floating-point number of seconds since the AudioContext was created. [...] Since there are around 15 decimal digits of precision in a “double”, even if the audio clock has been running for days, it should still have plenty of bits left over to point to a specific sample even at a high sample rate.
It is mindboggling to me that a floating-point representation was designed into this. The required precision is well known and won't change. It is also well understood that this precision is required "locally" at possibly large future values. Even having the value wrap is mostly not a problem. Floating point is the opposite of designing for these things… (and no other audio API I'm aware of does this.)
(Okay, after doing some quick math, a double precision float should be OK for more than 100 years. The mismatch still irks me…)
Javascript doesn't have integer types, only a 'number' type which is equivalent to a 'double', so even if the clock would use an integer representation internally it would need to be exposed as a floating point value in the WebAudio API.
It is mindboggling to me that a floating-point representation was designed into this. The required precision is well known and won't change. It is also well understood that this precision is required "locally" at possibly large future values. Even having the value wrap is mostly not a problem. Floating point is the opposite of designing for these things… (and no other audio API I'm aware of does this.)
(Okay, after doing some quick math, a double precision float should be OK for more than 100 years. The mismatch still irks me…)