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.
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
>>
>
