Sorry for the delayed reply.
Originally Posted by contrate_wheel
I am familiar with Audacity, but I have't been able to use it lately due to a library incompatibility problem that's come along with a recent software upgrade. The result is that when I attempt to record, Audacity does not use the sampling rate and bit depth that I specify and the results turn out to be unpredictable and inconsistent. Once I have it working again, what settings do you require as recording defaults?
Back to the subject of calibration -- I'm having trouble understanding why we have a quartz-referenced calibration procedure in the first place, for two reasons:
First, Quartz isn't all that accurate. That is to say, Quartz is better than most mechanical movements, but it's nowhere near as accurate as a computer clock that's running at megahertz frequencies. Quartz watch accuracy is on the order of +/- 500 milliseconds/day. Although that's better than many mechanical movements, 1/2 spd isn't a good accuracy reference if you're trying to measure a watch that has an accuracy on the order of 2 spd. The Nyquist theorem tells us that sampling at 2x the desired frequency is the absolute minimum acceptable standard. With a quartz reference we barely have enough accuracy to measure the performance of a mechanical chronometer with a resolution of +/- 2 spd.
Second, any modern computer is equipped with a Network Time Protocol based system clock that operates at megahertz frequency. My plain-Jane Fedora system uses Chronyd, which performs regular time-syncs, polling it's upstream time server every 2^6 seconds, and between polls it automatically compensates for any skew in the system clock. The following query shows that the NTP-calibrated system clock on my PC is 1.78 nanoseconds slow of NST.gov's atomic NTP time as I type this:
Nanosecond resolution is millions of times higher resolution than millisecond resolution. Using a quartz based reference that has accuracy on the order of 500 msec doesn't seem worth the effort when a call to the system clock can obtain time at 1.78 nsec resolution. That's actually a difference of what, 280 million times higher frequency?
# chronyc tracking
Reference ID : 0A0A0A01 (*********)
Stratum : 2
Ref time (UTC) : Mon Aug 13 22:58:52 2018
System time : 0.000001780 seconds slow of NTP time
Last offset : -0.000003389 seconds
RMS offset : 0.000005357 seconds
Frequency : 37.157 ppm fast
Residual freq : -0.002 ppm
Skew : 0.077 ppm
Root delay : 0.036606569 seconds
Root dispersion : 0.047560256 seconds
Update interval : 64.6 seconds
Leap status : Normal
Given that any modern PC uses NTP time sycing (Microsoft, Apple or Linux, take your pick), nanosecond level time accuracy is available on any modern PC. I don't understand why the timing software is querying the soundcard clock as a time reference, as the soundcard clock is uncalibrated. It also doesn't make sense to me why the software expects a user to use a quartz-based calibration procedure using an external time source (watch) when polling the system clock would provide a reference source for calibration that's accurate to the nanosecond level and is presumably hundreds of millions of times more accurate. Polling the soundcard for timing seems like it would provide a lesser result than polling the system clock on any NTP-based PC system.
I have to assume that I'm misunderstanding something. Thanks for your time.