Ticket #393 (WontFix)Mon Aug 04 13:08:03 UTC 2014
Timesetup needs an option for "network sync only at boot"
| Reported by: | Jim Nagel (444) | Severity: | Enhancement |
| Part: | RISC OS: Boot sequence | Release: | |
| Milestone: | Status | WontFix |
Details by Jim Nagel (444):
The equivalent component in Ro 4.39 (by Artifishial Software, 2003) has an option to sync the computer’s clock to an internet timeserver ONLY AT BOOT, whereas the Rool !Timesetup component requires the user to choose a time interval for repeated syncs during the whole session, which could potentially cause difficulties for users doing time-critical operations such as processing sound.
There is no documentation for !Timesetup, so the user cannot be clear how the continued background running of !Timesetup is going to affect critical timing in such an operation.
By the way, a couple of spelling mistakes could be corrected in the Messages file: Colombia (not u), Novosibirsk (not L).
Changelog:
Modified by Sprow (202) Sat, August 09 2014 - 07:52:09 GMT
- Status changed from Open to WontFix
No, it doesn’t, or at least to suggest that it does implies that its operation has been somewhat misunderstood – perhaps the topic for a magazine article?
Firstly of course !TimeSetup is only a front end either for manual time setting or for network time, and I guess it’s the network time aspect that this question mostly refers to. That’s handled by NetTime which has a functional spec https://www.riscosopen.org/viewer/view/castle/R… available.
The time adjustment is not made as a step jump forwards or backwards, but by slewing timer0 a few 100ppm either way to match the timeserver. Doing a ‘once at boot’ adjustment therefore would affect the system in exactly the same way as ‘once a day’ for example, since the slewing is continuous over time. Except that, if your machine has been turned off for a while, it’s likely that the initial slew might need to be ~1000’s ppm meaning the proposed option would likely make the sound processing worse, not better.
On which note, on no supported hardware platforms (that is, Risc PC and later) does timer0 come out on a connector that could be used to sync external audio capture or playback hardware so I fail to see why the rate of timer0 is of concern for audio. Even things like the BEAT counter are divided down off the audio sample rate, which isn’t derived from timer0. Only the monotonic 1cs tick comes from timer0 which would give a not-very-impressive 50Hz bandwidth for Nyquist sampling.
It’s a reasonably simple control loop so can be thought of a bit like looking through a telescope and adjusting the angle of a tennis ball launcher to try to hit a tennis player a few miles away. The granularity of the adjustments mean that at that distance the ball might land slightly short of the net, but that doesn’t matter as the next guess will be a little closer. One way to improve the accuracy is to make more guesses, which in NetTime terms is to get the time from the time server more often. At the opposite end of the scale making corrections every 30s is likely to result in a swerving oscillation too high/too low, which is why there’s a more sensible minimum period offered in !TimeSetup.
This style of slew should be familiar to anyone with a Risc PC or later machine, since it’s exactly the same as the RTCAdjust module has been doing for over 20 years, and nobody’s ever questioned its operation in the area of audio processing. You can see the algorithm in RTCAdjust
https://www.riscosopen.org/viewer/view/castle/R…
is the same as the one on NetTime
https://www.riscosopen.org/viewer/view/castle/R…
except it got converted into easier to read ‘C’. Post RISC OS 5.20 these were rationalised since it was silly to have two modules carrying the same code and having to check for eachother’s existance, so the RTC module now performs the slew. But the algorithm is unchanged
https://www.riscosopen.org/viewer/view/bsd/Risc…
so pick any as the reference.
In summary
a) once at boot wouldn’t actually change the slew
b) the slew doesn’t affect the audio system anyway
c) the algorithm is the same as RTCAdjust has always used
Thanks for the spelling mistakes though, now corrected. I watch a lot of Columbo so I guess my head autocorrected Colombia!
