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? 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. 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? -- blu "You would think that spies would have to be light sleepers, but that isn't true. For instance, James Bond once slept through an earthquake. That's right, he was shaken but not stirred." ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
