I had some time to do testing during holiday. I had several computers ranging from 300MHz to 2.8GHz and all based on Slackware 9.1 and ALSA from 0.9.6 to 1.0.1 (found 1.0.1 yesterday..). I patched the 2.4.23 kernel with the Andrew Morton's low-latency patch (with control via sysctl).
The test was carried out between two computers with an audio cable from output to the line input of the other one. Every ten minutes the real time clocks were synchronized from GPS-receivers (<< 1 ms error). After one minute, the recording was started from crontab on the "receiver" and again, after one minute, the "sender" computer started playback. After a few seconds both playback and recording were stopped.
I repeated this sequence with many computers changing the low-latency on and off. All needless daemons were killed and only needed kernel modules were present. The scripts were run with "nice -n -20".
The results are somehow expected but a disappointment for me. The dependent factor was total latency calculated by:
PlaybackStartTime-RecStartTime-CapturedDelay
->If playback start with delay, the signal will appear to the file later than it should.
->If recording starts with delay, the captured signal should have negative delay (signal will appear to the file before it should).
The average of these latencies was 246 ms without low-latency and by switching the low-latency on the average dropped to 30 ms! Using a laptop with all stuff on (e.g. apm-module and KDE-daemons), the latencies were > 1000 ms, but I don't consider those results.
Do you have any idea, where these latencies come from? I don't know how cron works, but that's one suspect. How about aplay and arecord-commands. I didn't give any "tuning" parameters.
Does anybody know a piece of software that starts recording "exactly" at a given moment (opens file, starts filling buffers before and begins file-io when clock says so).
Next I'll try this by capturing the signal first to a ramdisk. Any other ideas to test? I read some documentation of RTLinux and RTAI, but as far as I understand, then at least the audio capture command should be rewritten.
Yours, panu
------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Alsa-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-user
