Messages in this thread | | | Date | Mon, 26 Jul 1999 02:01:01 +0200 | From | Ove Ewerlid <> | Subject | Re: audio/PCI/mmap oddity |
| |
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/
| |