On Thu, Jan 28, 2010 at 03:01:38PM -0500, David McClanahan wrote: > On Tue, Jan 26, 2010 at 8:47 PM, David Olofson <da...@olofson.net> 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@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
