Re: [LAD] hard realtime performance synth

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: David Olofson <david@...>
Cc: <linux-audio-dev@...>
Date: Thursday, January 28, 2010 - 8:01 pm

--000e0cd51626a157f9047e3efc25
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 26, 2010 at 8:47 PM, David Olofson wrote:

> On Tuesday 26 January 2010, at 21.15.43, David McClanahan

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.

> Now, in real life, the "every time" part will never be quite accurate.

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

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

instrument I would think no buffering would be the ideal.

> With a properly configured "lowlatency" Linux system on decent hardware (as

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)

>

--000e0cd51626a157f9047e3efc25
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 26, 2010 at 8:47 PM, David O=
lofson <david@olo=
fson.net
> wrote:
On Tuesday 26 January 2010, at 21.15.43, David McClanahan
<david.m=
cclanahan@gmail.com
> wrote:
[...]

ing realtime systems. The
e

> system(simplistic I know) might entail a task whose sole job is to pum=
p out

time
il
d run
and

The relevant definition of "hard realtime system" here is &=
quot;a system that
always responds in bounded time." That bounded time may be one microse=
cond 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 incomp=
lete. Somebody can write a piece of software and performance test it on a &=
quot;soft realtime" system and it meet all its deadlines DURING THE TE=
ST. But a hard realtime system should have mechanisms(the scheduler and tim=
ing analysis of the code) to insure the deadlines are met. The current &quo=
t;RT patches" system is probablistic("cross your fingers"). =
It may be a good one and sufficient on most machines.
=A0
Now, in real life, the "every time" part will never be quite accu=
rate. 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 thin=
gs
that can go wrong in any non-trivial system.
Even in HRT systems, things go wrong. But in an HRT s=
ystem, you lash the squirrels nuts down. In a soft realtime system, you bet=
that there won't be a storm.=A0

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 syste=
m
would probably be ridiculously expensive, if it's even possible to buil=
d.
Triple redundancy hardware, code verified by NASA, various other things I&#=
39;ve
never even thought of; that sort of stuff...
Who wants a DAW. I'd be happy a while=A0 with a s=
table 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, B=
ristol locks up=A0 and then locks up the operating system as does Zyn. Flui=
dSynth 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 d=
edicated synth(unless it's of a "super" computer variety). I =
haven't heard anything yet that quite "put the nail in the coffin&=
quot; yet. The SMI issue mentioned earlier might be such an issue.
=A0
As to the 44 kHz "cycle rate" on the software level, although pos=
sible, 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 "reason=
ably reliable".
Well I understand it from that perspective, but for a=
performance instrument I would think no buffering would be the ideal. =
=A0

With a properly configured "lowlatency" Linux system on decent ha=
rdware (as
in, no BIOS super-NMIs blocking IRQs and stuf; raw performance is less of a=
n
issue), you can probably have a few days without a glitch, with a latency o=
f a
few milliseconds.

I haven't kept up with the latest developments, but I remember stress-t=
esting
the first generation lowlatency kernels by Ingo Molnar, at 3 ms latency wit=
h
80% "DSP" CPU load. Hours of X11 stress, disk I/O stress, CPU str=
ess 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 sayi=
ng
this will work with any lowlatency kernel on any hardware, but it's def=
initely
possible without a "real" RT kernel.
Well my question is if=
you took something like a Bristol synth, and operated multiple control str=
eams(pitch bend, filter sweeps, etc) if you would experience latency(ie you=
turn the knob and the pitch bends 1/2 hour later)
=A0

--
//David Olofson - Developer, Artist, Open Source Advocate

.--- Games, examples, libraries, scripting, sound, music, graphics ---.
| =A0http://olofson.net =A0 http://kobodeluxe=
.com
=A0 http://audi=
ality.org
=A0|

| =A0http://eel.olofso=
n.net
=A0http://zeesp=
ace.net
=A0 http://re=
ologica.se
=A0|

'---------------------------------------------------------------------&=
#39;
__________________________________=
_____________
Linux-audio-dev mailing list
Linux-audio-dev@lis=
ts.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev

--000e0cd51626a157f9047e3efc25--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAD] hard realtime performance synth, David McClanahan, (Sat Jan 23, 10:33 pm)
Re: [LAD] hard realtime performance synth, David McClanahan, (Tue Jan 26, 8:15 pm)
Re: [LAD] hard realtime performance synth, Jens M Andreasen, (Wed Jan 27, 8:40 am)
Re: [LAD] hard realtime performance synth, David Olofson, (Wed Jan 27, 1:48 am)
Re: [LAD] hard realtime performance synth, David McClanahan, (Thu Jan 28, 8:01 pm)
Re: [LAD] hard realtime performance synth, David Olofson, (Fri Jan 29, 1:32 am)
Re: [LAD] hard realtime performance synth, David McClanahan, (Fri Jan 29, 10:24 pm)
Re: [LAD] hard realtime performance synth, Gabriel M. Beddingfield, (Sat Jan 30, 5:37 am)
Re: [LAD] hard realtime performance synth, Paul Davis, (Sat Jan 30, 12:20 am)
Re: [LAD] hard realtime performance synth, Gabriel M. Beddingfield, (Thu Jan 28, 9:40 pm)
Re: [LAD] hard realtime performance synth, Folderol, (Thu Jan 28, 10:12 pm)
Re: [LAD] hard realtime performance synth, torbenh, (Thu Jan 28, 8:55 pm)
Re: [LAD] hard realtime performance synth, Louigi Verona, (Wed Jan 27, 1:51 am)
Re: [LAD] hard realtime performance synth, Louigi Verona, (Wed Jan 27, 1:34 am)
Re: [LAD] hard realtime performance synth, Stephen Sinclair, (Tue Jan 26, 9:48 pm)
Re: [LAD] hard realtime performance synth, David McClanahan, (Thu Jan 28, 6:55 pm)
Re: [LAD] hard realtime performance synth, Paul Davis, (Thu Jan 28, 7:56 pm)
Re: [LAD] hard realtime performance synth, David McClanahan, (Thu Jan 28, 8:07 pm)
Re: [LAD] hard realtime performance synth, Josh Lawrence, (Tue Jan 26, 8:39 pm)
Re: [LAD] hard realtime performance synth, Gabriel M. Beddingfield, (Sun Jan 24, 2:46 am)
Re: [LAD] hard realtime performance synth, Ray Rashif, (Sun Jan 24, 6:35 am)
Re: [LAD] hard realtime performance synth, Jens M Andreasen, (Sun Jan 24, 1:27 pm)
Re: [LAD] hard realtime performance synth, Louigi Verona, (Sun Jan 24, 2:46 pm)
Re: [LAD] hard realtime performance synth, Jens M Andreasen, (Sun Jan 24, 3:06 pm)
Re: [LAD] hard realtime performance synth, Victor Lazzarini, (Mon Jan 25, 6:16 pm)
Re: [LAD] hard realtime performance synth, Jens M Andreasen, (Mon Jan 25, 5:17 pm)
Re: [LAD] hard realtime performance synth, Gene Heskett, (Mon Jan 25, 6:32 pm)
Re: [LAD] hard realtime performance synth, Jens M Andreasen, (Mon Jan 25, 6:09 pm)