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, then
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
context
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 audio data, and
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:
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
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 simple one to one
