Re: Documentation request - realtime abilities and how to use them

> [...]
> but giving hard round-robin rt-priorities (like with
> sched_setscheduler(2))
> to a desktop application like beast is _not_ right. basically, with
> round-robin scheduling, beast threads would always run when needed, but
> also would get run if the code runs into a buggy endless-loop (e.g. within
> a LADSPA plugin), causing the machine to effectively halt.
> i.e. SCHED_RR or SCHED_FIFO is unly usefull if you can guarantee to some
> extend that your application is almost bug free. that's comlpetely
> impractical
> for an ordinary desktop application that loads third-party plugins though.

hmm, just a quick thought that springs up my mind but could be completely
for a professional user it might be less of a problem if the whole system
crashes when trying some crazy new ladspa plugin than if anything disturbs him
when just being on doing a master record for some work.

But i can'tr estimate now which case happens more often and which one is
really more disturbing - a master record can be repeatd easily too, or one can
integrate ways to get the work into a wav file that doesn't mind if running in

But my question derived from me thinking beast has those possibilities
already. So I come to a nes question: how do i avoid cliking and hanging, which
occurs for me even in the Party monster sample song, when just swithcing in the
beast gui from one synthesizer view to another while playing - this should
really not happen, an d setting nice to -20 doesn't help, either.
Or is it quite normal that this doesn't work on a 2000 MHZ processor?. 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]