28 Jan
2010
28 Jan
'10
4:01 p.m.
On Tue, Jan 26, 2010 at 8:47 PM, David Olofson <david(a)olofson.net> wrote:
On Tuesday 26 January 2010, at 21.15.43, David
McClanahan
<david.mcclanahan(a)gmail.com> wrote:
[...]
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.
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.
I agree with the definition but feel its a bit incomplete. Somebody can 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.
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.
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...
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.
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.
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".
Well I understand it from that perspective, but for a performance
instrument I
would think no buffering would be the ideal.
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.
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)
--
//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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev