That's great. Alas, I can't help with the testing, since I am in New Hampshire and the only shortwave radio available to me was unable to pick up either WWV or WWVB. If there is anybody in Broomfield that can give it a try, I would appreciate it. People in Broomfield ought to be able to pick up WWV on their fillings. 8-) Or if there is anybody in the Burlington area with a better Shortwave that I could tap into the audio signal for a little while, that would work too.
Garrett D'Amore wrote: > Garrett D'Amore wrote: >> Brian Utterback wrote: >>> I have a concern about this. As part of NTP version 4, there is >>> support for decoding the audio signal from the radio station WWV to >>> provide a fairly accurate reference clock. The code currently hard >>> codes the use of /dev/audio, but the NTP project has been very good >>> about incorporating code changes. However, it sounds like you are >>> saying that in the post Boomer world, there will be no way to access >>> the audio device directly without going through the mixer, right? >>> >>> Of course, this is audio input, so maybe that doesn't apply. Using >>> the mixer will likely make the WWV refclock useless. It is essential >>> that the latency between the time that the signal reaches the >>> hardware and the time that the audio arrives in the ntpd daemon's >>> buffer be as small as possible. Failing that, the delays must be >>> consistent and without jitter. Is this going to be a problem post >>> Boomer? >> >> There should be very little jitter. >> >> The delays themselves are dependent on a few things: >> >> 1) the time from when the audio device receives the data until it >> interrupts us (at about 175 Hz, ~5-6 ms delay) >> 2) buffering done by the framework (currently 8K, and not tunable, but >> I'll fix that this week) as requested by application >> 3) the amount of data in STREAMS queues above the application >> >> I hadn't perceived a need for a smaller record buffer size than 8K, >> but I know understand why there would be. I'll make it tunable -- it >> won't be very hard to do. > > Btw, it will be possible for applications to request *no* buffering of > record data be performed. In which case we'll send it up as soon as > we've got it. :-) > > -- Garrett >> >> At the end of the day, we should be able to support NTP. >> >> Can you help with testing/validation of Boomer with NTP in this >> capacity? (I don't have the WWV equipment or expertise to test this >> myself.) >> >> -- Garrett >>> >>> Garrett D'Amore wrote: >>>> Bart Smaalders wrote: >>>>> Garrett D'Amore wrote: >>>>>> Please let us know if there are any concerns about any of the above. >>>>>> >>>>> >>>>> >>>>> This looks good, Garrett. Can we also obsolete the ability to >>>>> disable the mixer in mixerctl? I don't want to force all applications >>>>> to have to deal with open calls to /dev/audio blocking indefinitely. >>>> >>>> Yes, I'm sorry -- I thought I had already indicated this in the >>>> inception materials. It is not possible to disable the mixer. All >>>> support for any kind of "exclusive mode" access was removed in the >>>> Boomer gate a long time ago. :-) >>>> >>>> I suppose there might be certain *ancient* applications this >>>> breaks... but such applications would not have played well with >>>> other uses of the audio device anyway (include any use by desktop >>>> environments like gnome!) >>>> >>>> -- Garrett >>>> >>> >> > -- blu "Murderous organizations have increased in size and scope; they are more daring, they are served by the most terrible weapons offered by modern science, and the world is nowadays threatened by new forces which, if recklessly unchained, may some day wreak universal destruction." - Arthur Griffith, 1898 ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
