On Thursday 11 April 2002 16:37, SIMON Benjamin wrote:
> First, thank you for your answer.
> I see your point.
>
> However, I was wondering:
> Is it clever or completely stupid to envisage the following issue:
> - reading and writting audio data is done by a non-RT process and uses
> the linux driver of the soundcard.
> - a realtime thread processes the audio signal.
> - RT and non-RT threads communicate using RTFifos.
>
> What are the limits of such an implementation?
Well, latency is dictated by the "determinism" of standard Linux. In
other words, there isn't much point in using RTL for the processing at
all, unless the I/O is done entirely in RTL context as well.
> What I mean is that in
> case of high rates, high sampling frequency (which implies to read and
> write more Data), would it slow the RT-processing part of the
> application down?
I'm not quite sure what you mean. The CPU isn't magically faster in RTL
context or anything ;-), so there shouldn't be a difference... What
matters is whether or not you manage to read, process and write the data
all the time without getting buffer xruns.
Anyway, there's another thing to keep in mind here: Most sound cards
(read: all PCI sound cards, and a few ISA cards) have rather noticable
h/w restrictions WRT latency. Don't expect to get much lower than some .3
ms *digital* latency - and then consider the AD/DA filter latency, which
adds anything between .5 and several ms to the latency!
In short, there isn't much point in using RTLinux for audio, unless you
need extremely high reliability, or maximum CPU utilization on SMP
systems in multithreaded DSP applications.
For "normal" use, including serious studio use (where Windows and Mac OS
based solutions have to resort to dedicated DSP hardware), some form of
Linux/lowlatency and/or kpreempt patched kernel should do just fine. It's
possible to achieve "guaranteed" worst case scheduling latencies in the <
.5 ms range, which is sufficient for most audio processing applications,
even when most of the available CPU time is needed for processing. ("80%
for DSP" is a common benchmark setting during extreme system stress...
Works fine.) Check out:
http://www2.linuxaudiodev.org/audio/lad/resourceslatency.php3
The good old 2.2.10-lowlatency still seems to be one of the best, but
some people have achieved very promising performance with both kpreempt
(2.5.x) and lowlatency applied. (kpreempt in itself is far from
sufficient, as there's much more work to do in the kernel WRT locking and
stuff; preemption just turns out to be prevented all to often, so there
will be occasional latency peaks in the 5-10 ms range. Results so far
seem to indicate that chances are good that all of this will be fixed in
2.6, though.)
//David Olofson --- Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------------> http://www.linuxdj.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-------------------------------------> http://olofson.net -'
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/
