Date: Sat, 29 Mar 2003 10:28:35 -0800 From: "Kevin Oberman" <oberman@es.net> To: Orion Hodson <orion@freebsd.org> Cc: current@freebsd.org Subject: Re: AC97 sound problems with current Message-ID: <20030329182835.B1F0269@ptavv.es.net> In-Reply-To: Message from Orion Hodson <orion@freebsd.org> <200303290121.h2T1LjAT046939@puma.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> From: Orion Hodson <orion@freebsd.org> > Date: Fri, 28 Mar 2003 17:21:45 -0800 > Sender: hodson@icir.org > > > Kevin Oberman writes: > | More information on my AC97 experiences: > | > | I forced the card to 4.8 KHz which is what it was running at on V4. This > | seems to have not helped the performance of GnomeMeeting at all. The > | sound I hear is in "spurts" which are at the correct frequency and last > | about a tenth of a second. with gaps between them of about 1 second. > > Is 4.8kHz a typo? It should be 48kHz or 55913Hz depending on your > h/w. Which of the two is all the calibration test is supposed to > determine. Some ac97 controllers on ich based systems seem to end up > using an alternate clock source: XTAL_IN rather than BIT_CLK. The > former clocks the AC97 link at around 55913Hz when it should be at > 48kHz. It wasn't clear to me until recently that this was what was > happening and until some more testing is done I'm not sure if it's a > feature of the ich driver ac97 initialization or just the way it is. Yes, 4.8 KHz was a typo. I meant 48 KHz. My desktop systems (ICH2)m both run at 55913 Hz while my laptop was running at 48 KHz under V4. > I'm currently configuring a laptop to be a netboot server and will > sneak up on an unsuspecting ich machine in the next couple of days and > endeavor to resolve the problem in situ (right now I'm dog tired of > exchanging patches for remote h/w, but that's not to say the offers > are not appreciated in general). Thanks so much. I'm on travel for a week, although I will be on-line using the laptop running current through Wednesday. I'll be more than happy to try patches or provide any information I can to help, though I understand how painful remote debugging can be. (Keeping a national high-performance network running involves way too much use of remote hands, even with lots of out-of-band access capability.) The clocking test failure is easy to work around, so the duplex operation problems are of far more concern as I need duplex for teleconferencing which my job often calls for. Back to Windows and NetMeeting in the interim. :-( R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030329182835.B1F0269>