On Sun, 2002-12-08 at 16:14, Kai Vehmanen wrote:
> On Sun, 8 Dec 2002, Paul Davis wrote:
>
> > you also haven't addressed kernel scheduling issues; the context
> > switch doesn't happen till the kernel has decided what task is going
> > to run next. if it picks the wrong one, for whatever reason,
On Sun, 8 Dec 2002, Paul Davis wrote:
> >> >I'm not talking about jack tasks, I'm talking about doing a simple
> >plug-in
> >> >task inside a standalone program, the way the vst server works.
> >>
> >> i don't understand how the vst server works. perhaps you can explain
> >> it.
> >
> >Its just
On Sun, 8 Dec 2002, Paul Davis wrote:
> you also haven't addressed kernel scheduling issues; the context
> switch doesn't happen till the kernel has decided what task is going
> to run next. if it picks the wrong one, for whatever reason, then
> you/we lose. right now, it picks the wrong one too o
>Yupp, I see. I get a 7 percent penalty compaired to doing
>the same just in one process.
right. now try it with 8 different processes, all of them touching
enough (different) data to invalidate a random selection of about 80%
of the cache. or better yet, just take our word for it that the cost
of
On Sun, 8 Dec 2002, Paul Davis wrote:
> Kjetil and i have been boring the VST crew to death. so we took it
> here :)
>
> >> because when running a real-time low-latency audio system, the cost of
> >> context switches is comparatively large. if you've got 1500usecs to
> >> process a chunk of audi
Kjetil and i have been boring the VST crew to death. so we took it
here :)
>> because when running a real-time low-latency audio system, the cost of
>> context switches is comparatively large. if you've got 1500usecs to
>> process a chunk of audio data, and you spend 150usecs of it doing
>> contex
