On Fri, Apr 02, 2010 at 06:57:54PM -0700, J.C. Roberts wrote: > On Fri, 2 Apr 2010 22:45:12 +0200 Alexandre Ratchov <a...@caoua.org> > wrote: > > > > A short summary of the changes: > > > > > > - According to specification AUICH_RR may only be set after DMA > > > is halted (AUICH_DCH is 0 in AUICH_STS). To accomplish this I > > > revived auich_halt_pipe(); > > > - auich_calibrate() did not clear interrupt and event bits in > > > AUICH_STS. Do that now. Further it did watch the CIV index > > > counter to see when all samples are processed. I changed it to > > > watch AUICH_STS instead and set LVI=CIV. therefore it won't > > > change the CIV counter. > > > - my last patch introduced a small bug in auich_trigger_pipe() I > > > fixed that. > > > > > > > I think we should put the corresponding chunk in, sooner > > than later. > > > > BTW, I start wondering why this calibration exists at all? > > do devices running at the wrong rate exist (which would mean > > they don't have the proper clock). If so should we start > > adding calibration code in all of our audio drivers? > > > > -- Alexandre > > Take a look at the last line of the dmesg below (taken just a moment > ago). The system has been up for about a day, and the last line was > added some time after it first booted up. It's typically not seen right > after a fresh cold boot. A *nearly* identical system running a newer > snapshot doesn't have the last speed tweak line. As for what exactly > the speed tweak actually means, I'm not entirely certain. --It kind of > smells like the improper clock you mentioned above, but it does seem to > answer your question if devices running at the wrong rate exist.
> auich0: measured ac97 link rate at 48008 Hz, will use 48000 Hz 0.017% deviation is negligible. src/regress/sys/dev/audio measures the difference in audio and system clocks. I wonder how those ISA cards compare to the auich ;) -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
