<br><br><div class="gmail_quote">On Tue, Jan 26, 2010 at 8:47 PM, 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></blockquote><div>I agree with the definition but feel its a bit incomplete. Somebody can write a piece of software and performance test it on a "soft realtime" system and it meet all its deadlines DURING THE TEST. But a hard realtime system should have mechanisms(the scheduler and timing analysis of the code) to insure the deadlines are met. The current "RT patches" system is probablistic("cross your fingers"). It may be a good one and sufficient on most machines. <br>
<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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></blockquote><div>Even in HRT systems, things go wrong. But in an HRT system, you lash the squirrels nuts down. In a soft realtime system, you bet that there won't be a storm.<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

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></blockquote><div>Who wants a DAW. I'd be happy a while  with a stable minimoog emulator. The Bristol has that and CS80(descendant of Yamaha's GX-1). It'd be cool just to have a stable, glitch a day, analog-like synth such as these. As it is now with Ubuntu's Studio packages, Bristol locks up  and then locks up the operating system as does Zyn. FluidSynth works but will glitch quite a bit.<br>
<br>Well there are affordable synths(mostly wavetable ones) that don't appear any more sophisticated hardware-wise than a PC. The PC may be such a "generalized" piece of hardware as to make it impractical as a dedicated synth(unless it's of a "super" computer variety). I haven't heard anything yet that quite "put the nail in the coffin" yet. The SMI issue mentioned earlier might be such an issue.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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></blockquote><div>Well I understand it from that perspective, but for a performance instrument I would think no buffering would be the ideal. <br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

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></font></blockquote><div>Well my question is if you took something like a Bristol synth, and operated multiple control streams(pitch bend, filter sweeps, etc) if you would experience latency(ie you turn the knob and the pitch bends 1/2 hour later)<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><font color="#888888">
<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>