Brian Utterback wrote:
>
>
> Garrett D'Amore wrote:
>
>> Ok, so I don't know what this means. Will the audio clock use OSS or
>> Sun audio? The Sun audio probably has a *lot* more jitter (perhaps
>> unacceptably large?) than the OSS API does. Since ntp *must* support
>> the OSS audio device (if it wants to work with FreeBSD at least,
>> which I believe it does), I'd like supporting Boomer to be a
>> requirement for this case going forward. (Put another way, I don't
>> want to have to deal with bugs from this project using the legacy Sun
>> audio interfaces...)
>
> What would you find acceptable? I can see that there are in fact three
> refclock drivers that read audio data and decode it. All three use
> /dev/audio as the default device. All three have the ability to
> override this. I installed RC3 of boomer and /dev/audio is a symlink
> to /dev/sound/0, so it would appear that things that open /dev/audio
> should still work anyway, no?
Yes, although I don't necessarily guarantee that you'll still get these
as low latency items.
>
> Do you want these drivers to do something different for Boomer? As a
> NTP committer, I can pretty much guarantee that we will not treat any
> issues with audio post-Boomer integration as a Sun bug unless it is
> also a bug in Boomer. That is, if these drivers fail using Boomer when
> they worked on Sun Audio, then we will treat that as a NTP bug until
> we can all agree that it is correctly using the Boomer API.
Ok.
>
> To the point, we can commit that we will not ask you to support legacy
> Sun Audio interfaces usage in NTP on platforms with OSS installed. Is
> that good enough?
Yes. :-) Thanks. (I'd recommend building/delivering with OSS API
enabled by default, to get the best latency/jitter possible.)
- Garrett
