Re: Sampling Rate Problem - AEC
- From: NoSpam@xxxxxxxxxxx (Bob Masta)
- Date: Wed, 20 Sep 2006 12:43:30 GMT
On 19 Sep 2006 23:21:23 -0700, venu.annamraju@xxxxxxxxx wrote:
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
Sorry, I have asked this same question myself and was
told that there is no way to disable SRC, nor even to
know when it is working, via software alone. I believe
Chris P. discussed a way to force input and output to
be in sync, but my recollection is that you couldn't also
specify the sample rate. (Also, they were in sync as
far as having the rates locked, but the alignment was
still arbitrary and unknown.)
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.
Are we talking about 2 different things here? The DMA transfer rate
should have no bearing on sample rate, jusy how fast the buffers
get transferred from chipset to CPU memory. Or do some chipsets
do a transfer on each sample? I guess that would allow them to use
a very shallow FIFO. I was under the (mistaken?) impression that most
chipsets used the FIFO approach these days, to be able to ride out
long Windows latencies.
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.
I use a somewhat similar method on a single chipset. I generate
an output pulse at a relatively slow rate (5/sec) and monitor it with
a loopback to the input. Then I scan through the samples to identify
the pulse on the input line. (The slow spacing is so I am sure I
know *which* pulse I have found, to get absolute alignment.)
Then since I know how many samples apart the output pulses were as
generated, I know where to look for subsequent input pulses and can
determine if they are drifing, and which direction.
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
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
.
- References:
- Sampling Rate Problem - AEC
- From: venu . annamraju
- Re: Sampling Rate Problem - AEC
- From: Bob Masta
- Re: Sampling Rate Problem - AEC
- From: venu . annamraju
- Sampling Rate Problem - AEC
- Prev by Date: Re: Sampling Rate Problem - AEC
- Next by Date: Re: How do I create a spectral view for wav files?
- Previous by thread: Re: Sampling Rate Problem - AEC
- Next by thread: Re: Sampling Rate Problem - AEC
- Index(es):
Relevant Pages
|