Which is interesting. I did not notice on my ASUS laptop any significant difference between rt-kernel<br>and a normal one. It was there - a bit less dropouts, but the change was not significant, meaning that<br>my non RT kernel mode works almost as good.<br>
<br><div class="gmail_quote">On Wed, Jan 27, 2010 at 9:47 AM, David Olofson <span dir="ltr"><<a href="mailto:david@olofson.net">david@olofson.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Tuesday 26 January 2010, at 21.15.43, David McClanahan<br>
<div class="im"><<a href="mailto:david.mcclanahan@gmail.com">david.mcclanahan@gmail.com</a>> wrote:<br>
</div>[...]<br>
<div class="im">> 3. I'm a little worried about what some are calling realtime systems. The<br>
> realtime system that is part of Ubuntu Studio and others may be more<br>
> preemptible than the normal kernel(as in kernel calls themselves can be<br>
> preempted), but that's not a hard realtime system. A hard realtime<br>
> system(simplistic I know) might entail a task whose sole job is to pump out<br>
> a sinusoidal sound sample to the D-to-A on the sound card. A hard realtime<br>
> scheduler would run that task at 44Khz no matter what. This would entail<br>
> developing code that when the machine instructions were analyzed, would run<br>
> in the time constraints(aka the 44Khz). RTLinux appears to be suitable and<br>
> RTAI might be. Perhaps others.<br>
<br>
</div>The relevant definition of "hard realtime system" here is "a system that<br>
always responds in bounded time." That bounded time may be one microsecond or<br>
one hour, but as long as the system can meet it's deadline every time, it's a<br>
hard realtime system. The definition doesn't really imply any specific time<br>
frames.<br>
<br>
Now, in real life, the "every time" part will never be quite accurate. After<br>
all, you may see some "once in a billion" combination of hardware events that<br>
delays your IRQ a few microseconds too many, or your lose power, or the<br>
hardware breaks down, or a software bug strikes... There are countless things<br>
that can go wrong in any non-trivial system.<br>
<br>
Of course, there's a big difference between a DAW that drops out a few times a<br>
day, and one that runs rock solid for weeks - but a truly glitch-free system<br>
would probably be ridiculously expensive, if it's even possible to build.<br>
Triple redundancy hardware, code verified by NASA, various other things I've<br>
never even thought of; that sort of stuff...<br>
<br>
As to the 44 kHz "cycle rate" on the software level, although possible, is big<br>
waste of CPU power on any general purpose CPU, as the IRQ and context<br>
switching overhead will be quite substantial. Further, even the (normally<br>
irrelevant) worst case scheduling jitter starts making a significant impact on<br>
the maximum safe "DSP" CPU load. (Double the cycle rate, and the constant<br>
jitter makes twice the impact.)<br>
<br>
Therefore, most low latency audio applications (whether on PCs/workstations or<br>
dedicated hardware) process a bunch of samples at a time, usually somewhere<br>
around one millisecond's worth of audio. This allows you to use nearly all<br>
available CPU power for actual DSP work, and you don't even need to use an<br>
"extreme" RTOS like RTAI/LXRT or RT-Linux to make it "reasonably reliable".<br>
<br>
With a properly configured "lowlatency" Linux system on decent hardware (as<br>
in, no BIOS super-NMIs blocking IRQs and stuf; raw performance is less of an<br>
issue), you can probably have a few days without a glitch, with a latency of a<br>
few milliseconds.<br>
<br>
I haven't kept up with the latest developments, but I remember stress-testing<br>
the first generation lowlatency kernels by Ingo Molnar, at 3 ms latency with<br>
80% "DSP" CPU load. Hours of X11 stress, disk I/O stress, CPU stress and<br>
combined stress, without a single drop-out. This was back in the Pentium II<br>
days, and IIRC, the fastest CPU I tested on was a 333 MHz Celeron. Not saying<br>
this will work with any lowlatency kernel on any hardware, but it's definitely<br>
possible without a "real" RT kernel.<br>
<font color="#888888"><br>
<br>
--<br>
//David Olofson - Developer, Artist, Open Source Advocate<br>
<br>
.--- Games, examples, libraries, scripting, sound, music, graphics ---.<br>
|  <a href="http://olofson.net" target="_blank">http://olofson.net</a>   <a href="http://kobodeluxe.com" target="_blank">http://kobodeluxe.com</a>   <a href="http://audiality.org" target="_blank">http://audiality.org</a>  |<br>

|  <a href="http://eel.olofson.net" target="_blank">http://eel.olofson.net</a>  <a href="http://zeespace.net" target="_blank">http://zeespace.net</a>   <a href="http://reologica.se" target="_blank">http://reologica.se</a>  |<br>

'---------------------------------------------------------------------'<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Linux-audio-dev mailing list<br>
<a href="mailto:Linux-audio-dev@lists.linuxaudio.org">Linux-audio-dev@lists.linuxaudio.org</a><br>
<a href="http://lists.linuxaudio.org/listinfo/linux-audio-dev" target="_blank">http://lists.linuxaudio.org/listinfo/linux-audio-dev</a><br>
</div></div></blockquote></div><br>