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