Re: [LAD] hard realtime performance synth

From: Louigi Verona <louigi.verona@email-addr-hidden>
Date: Wed Jan 27 2010 - 03:51:30 EET

Which is interesting. I did not notice on my ASUS laptop any significant
difference between rt-kernel
and a normal one. It was there - a bit less dropouts, but the change was not
significant, meaning that
my non RT kernel mode works almost as good.

On Wed, Jan 27, 2010 at 9:47 AM, David Olofson <david@email-addr-hidden> wrote:

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

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Jan 27 04:15:03 2010

This archive was generated by hypermail 2.1.8 : Wed Jan 27 2010 - 04:15:04 EET