The locked process still takes signals and faitfully exits when you kill
it!
Locked yes, but certainly killable and you do get that segfault instead
of system lookup ...
> > The worst case _conditionals_ are usually not a problem.
>
> No, not on a system that's _synchronized_ as opposed to a DSP loop
> padded with NOPs...
A DSP loop on a PII never need to be padded with NOP's due to the rdtsc!
> > Linux can deal with this scenario just fine as long as it has CPU
> > locking.
>
> I'd say that's more "working around Linux" than "Linux dealing with it",
> but so what; it works! :-)
Linux has full control over the locked process and it is completly
sandboxed!
> Much like a DSP card, but with a lot faster "card<->host" communication,
> a niced development environment, lower price, more power and no weird
> hardware that's hard to get at. :-)
Jupp!
> Yep, but if I can do with the jitter caused by cache misses and the
> latency lower limit implied by context switching, I think using, say 80%
> of BOTH CPUs is pretty interesting too. And that's good enough for most
This is what I'm saying!
(In my case the non locked CPU executes Matlab code in your case it
executes audiality ...)
> kinds of music/audio processing, which is what I'm most interested in.
> However, locking one CPU for ultra low latency processing, and using 50%
> of the other one for RTL at higher latency could be pretty
> interesting...
It is!
> Agree, and I have to admit that this discussion made me realize that my
> old ideas of single sample input->output latency may not be completely
> impossible, at least not on SMP systems. By compiling plug-ins
> "statements" into a tight loop executed on the locked CPU when the user
> changes the signal routing, this kind of latency may even be possible to
> use in a quite transparent way.
Nice idea!
It is a pitty that modern sound cards and modern busses are optimized
for
bandwith rather then latency. Even though the CPU can operate on a
per sample basis the sound card may deliver data in bursts of 64 samples
...
> My hihest priority is end users being able to get their audio
> recording/editing/processing work done as reliably on a PC as on
> dedicated hardware, and less than 1 ms of latency isn't really
> necessary. But why stop at that? What's pointless overkill today is an
> expected feature tomorrow...
Exactly :-)
Ove
PS; I'm talking about matlab above, it is a great tool but I do not
like the monopoly like situation Mathworks have ... but they
support Linux quite nicely!
-- Ove Ewerlid Ove.Ewerlid@syscon.uu.se or Ove.Ewerlid@signal.uu.se Phone: +46 70 666 23 63, Fax: +46 18 503 611, +46 18 555 096- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/