Re: [LAD] hard realtime performance synth

From: torbenh <torbenh@email-addr-hidden>
Date: Thu Jan 28 2010 - 22:55:16 EET

On Thu, Jan 28, 2010 at 03:01:38PM -0500, David McClanahan wrote:
> On Tue, Jan 26, 2010 at 8:47 PM, David Olofson <david@email-addr-hidden> wrote:
>
>
> > 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.

i still dont understand how building a highway, can speed up a bicycle
with a flat tire.

you should try a car on a normal road. will get you where you want.

>
>
>
> > 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.

you named the set of synths which are not RT safe.
(i dont really know about fluidsynth, but zyn and especially bristol
arent clean)

thats what i meant with bicycle.

> >
> > Well I understand it from that perspective, but for a performance
> instrument I would think no buffering would be the ideal.

we are talking about a buffer of 3ms here.
sound travels about 1 meter in that time.

-- 
torben Hohn
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Fri Jan 29 00:15:03 2010

This archive was generated by hypermail 2.1.8 : Fri Jan 29 2010 - 00:15:03 EET