Date: Tue, 23 Dec 1997 12:46:38 +0100 (MET) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: steve@visint.co.uk (Stephen Roome) Cc: hasty@rah.star-gate.com, multimedia@FreeBSD.ORG Subject: Re: precise soundcard tuning ? Message-ID: <199712231146.MAA04078@labinfo.iet.unipi.it> In-Reply-To: <Pine.BSF.3.96.971223114156.9149F-100000@dylan.visint.co.uk> from "Stephen Roome" at Dec 23, 97 11:59:13 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > After about 7 minutes or so: > > 3112000 388.919 8001.66 > <snipped results> > > Okay, I've not had a chance to test this one yet, but I don't think that's > the problem I was initially experiencing. > > I was playing a 440 Hz wave and it was coming back somewhere between a G > (391Hz) and a G# (416Hz). It's nearer G# to be fair, but that's still at > least 5.45% out. well i thought I should not post anymore on the subject but I feel some clarification is necessary here. the sample frequency on soundcards is generally derived by dividing some reference clock (usually a cristal) by some integer number. When the sample frequency is not an exact divisor of the cristal frequency, then some minor discrepancies might arise. As an example: on the CS423x (GUS and others) one of the cristal can run at 24.576 MHz which is 24576000 = 3072*8000 this means that (within the accuracy of the crystal, which should be in the 30-1000ppm range) you can have "nominal" sample rates for 8,16,24,32,48KHz. But 24576000/44100 = 557.27891 meaning that you cannot have 44.1 Khz, the closest approximation being 44122Hz (assuming you have a 10-bit programmable divisor). There are two ways to solve the problem: one (implemented on the CS423x) is to have a second cristal which runs at an integer multiple of the 44.1KHz frequency; the other one is to implement a true frequency sinthesizer which allows you to have any frequency which can be represented by a rational fraction (within some constraints, mainly dependent on the number of bits used in the PLL). In both cases the additional complexity in the circuit is close to zero (considering that most modern codecs already have a great deal of internal logic). With this in mind, even with my not-certainly-favourable view of Creative hardware, I can hardly believe that the hardware is really off by 5% at low sampling frequency. I am much more inclined to believe that a fair amount of the offset comes from the software driver which might compute the wrong value (because of approximations in integer computations) to poke into the speed selection registers. Ultimately this might well be Creative's fault given how criptic is their documentation! > Even combining any inaccuracies in my RTC, with the sound card 5% is quite > a big swing. > > So, I'm still going with your original (if defamatory) statement about > sound blaster cards, my Creative Labs cdrom drive isn't any better either. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712231146.MAA04078>