Re: audio/PCI/mmap oddity

Ove Ewerlid (Ove.Ewerlid@syscon.uu.se)
Mon, 26 Jul 1999 02:01:01 +0200


Paul Barton-Davis wrote:
>
> can anyone shed any possible light on this problem ? I just made some
> small modifications to ALSA to allow mmap() to be used with the native
> ALSA PCM interface. then i wrote a test program to use it. it maps the
> ADC buffer into user space, then alternates between scribbling magic 4
> byte patterns in various locations in the buffer and busy-waiting for
> them to be erased as the ADC overwrites them.

You do not busy wait as this is a rather extreme form of phase locking!
There is no need to have that _fast_ tracking of phase, as no
phase changes are expected. Instead, estimate the frequency/phase of
the
sound card DMA update and use the cycle counter rdtsc to wait for
the next predicted DMA buffer update. And, as you point out, you
can read samples in blocks (no need to go lower then the PCI
bus master DMA burst size). Ofcourse, your processor probably have other
useful things to do then just busy waiting ...

[ Tips, if you use any tool for numeric matrix computations with good
graphical presentation capabilities, run your tests under this tool
to be able to plot timing information easily. You will learn a lot
about your hardware by staring at graphs with real-time data collected
using rdtsc. Personally I use Matlab and CMEX (dynamically loadable
C/C++ code) with a small hack to make matrices shared from other
processes, e.g., you get snapshots of your DSP algorithms directly
into matrices that you can plot. (Code to make real-time FFT
spectrograms become trivial :-). ]

> however, when i use it with a PCI soundcard, quite often the pattern
> erasing skips a pattern or two. lets say i wrote 128 copies of my 4
> byte pattern throughout the ADC buffer. i would expect them to erased
> in order. But instead, if i was waiting for pattern #10 to be erased,
> i will find that pattern #11 has been overwritten but pattern #10 is
> still in place.

It is not evident but I assume you sample 2 channels at 16 bit.
You need to wait until both samples has changed from the magic.
The order is not relevant as you simply need not check until you
expect the data to have changed. This can be accomplished with proper
phaselocking/phasedelaying. (Ofcourse, your sound card or bus may do
very strange things but at least we do not expect out-of-order
problems al'a UDP in a PCI bus ... in ten years maybe ...)
Sacrifice one sample delay (or as many as it takes) to always read
data when you know it is consistent.

Ove

-- 
Ove Ewerlid
Ove.Ewerlid@syscon.uu.se or Ove.Ewerlid@signal.uu.se
Phone: +46 70 666 23 63, Fax: +46 18 503 611, +46 18 555 096

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/