Re: Sampling Rate Problem - AEC

Hi Bob

Is there a way to disable the Kmixer SRC so that when I request 8K
it does not do this:
SRC DMA
8K------->44K--------->44K
but this :
DMA
8K---------->8K

On some of your questions....

TWO CLOCK ISSUE:
1) Most soundcard chipsets do have Master/Slave option where the
speaker clock is provided by either the CPU peripheral clock or the
sound card's on-board crystal.
2) In master mode, the sync(for DMA transfers) will be provided by the
crystal clock, while in slave mode the sync is provided by the CPU
peripheral clock.
3) in OMAP850 pocket PC platform the default behavior uses two clocks!
(I cant say the same for PC soundcards though, because the drift does
dissappear for the "right" sampling rate)

CPU OR CRYSTAL CLOCK ?
1) There may be no drift on a soundard when we use the right sampling
rate, however we still may not know which clock is being used.
2) One technique I have invented(?) for determining the clock being
used is by clock skew. Using two soundcards, cross couple the mic1
-speaker2 and mic2-speaker1 and observe the inter-card drift. Usually
one reading will increase and the other will decrease. If both cards
use CPU clock then the inter-card drift will be say 1 sample in 400
seconds, otherwise the drift will be much faster.

AC-97:
1) In some audio chipsets used for mobile apps, only 8/16K is supported
for mic path whereas 44K is default rate(supports sub multiples also).
For speaker mode 8K can be configured using some special settings known
as Voice Serial Port at the hardware level.

Any help would be welcome. Maybe Chris P can throw some light on
this... I have been following his replies on similar issues.

thanks

venu


Bob Masta wrote:
On 18 Sep 2006 02:42:59 -0700, venu.annamraju@xxxxxxxxx wrote:

Hello All

I need to ensure the waveapi use 8K sampling rate for wavein and
waveout without any sample rate conversion. In the hardware, apparently
there is an option that can force this, even if this is not the case by
default.

I am using Wave apis on an Pocket PC platform.
If I use the wavein and waveout interfaces at 8K sampling rate, there
is drift in the samples which is bad for AEC.

I can think of two possibilities causing this problem
a) The default audio driver behavior uses two clocks. Generally
playback uses audio hardware clock, record uses a derivation CPU master
clock in the master mode settings (default) of the Audio hardware. CPU
master clock is used in both directions for Slave Mode setting, but
there seems to be no mechanism to access it from user level.

I'd be really surprised if this were the case. At least for "normal"
sound cards and chipsets, AFAIK, all use the card's internal
clock for everything. I can't imagine why they would use the CPU
clock, since they have already got a better one onboard for audio.
I would imagine Pocket PC would do the same.

b) Sampling rate conversion (from 44.1K to 8K) in the playback path
causing drift. The Windows mixer may be using a sample rate conversion
which is causing the drift.


I think this is the real culprit, combined with the fact that Windows
assumes all rates are integer Hertz. Typically the audio chipset
uses a clock that gives an exact sample rate at only 44100 or 48000,
by conversion from some higher crystal frequency in a Phase Locked
Loop. The sample rate is set by a divider in the loop, and it only
has certain frequency steps it can hit. I haven't measured recent
sound cards, but the old ISA-bus Sound Blasters used step sizes
of 177.8225... Hz for models that had exact 44100 Hz rates,
or 177.7778 Hz for a few models that had exact 48000 Hz rates.

So only when the divider is at the design rate, and maybe integer
submultiples of it, do you get the rate you think you have. Most
all other rates are off, by an error that may be as big as half the
card's sample rate step size.

My suspicion is that Windows SRC is using an idealized integer
Hz rate (or at least not the true card sample rate), and the
difference from the true rate shows up when you are converting one
stream up and the other down. Suppose the low sample rate is
something like 1/(6.02) times the actual high rate, but Windows thinks
it is 1/6. The in one direction it is multiplying by 6 instead of
6.02, and the other direction it is dividing by 6 instead of 6.02.

My questions:
a) Is there a simple solution to force both paths to use same clock and
sampling rate, since the option does exist at hardware level.
b) Can Windows Mobile DDK help in modifying the behavior for the
specific target?

Your input will be deeply appreciated, since I am grappling with this
problem for quite some time


I also have grappled with this, and the best I have come up with
is to use only the "right" sample rate for the chipset when in
full-duplex mode. The only way I have found to determine that
"right" rate is by a loopback and drift test... not exactly practical
for a general-use program. But it might be reasonable if all
Pocket PCs use the same audio chipset. (Do they?)

Actaully, I'd have guessed that they woud all use AC'97 sets
with 48000 Hz sample rate, and I'd have thought that since
8000 is exactly 1/6 it would have worked out fine. So maybe
my supposition about the cause of the problem is wrong...

If you find an answer, please let us know!

Best regards,



Bob Masta
dqatechATdaqartaDOTcom

D A Q A R T A
Data AcQuisition And Real-Time Analysis
www.daqarta.com
Home of DaqGen, the FREEWARE signal generator

.