10 Dec
2002
10 Dec
'02
5:33 p.m.
On Tuesday 10 December 2002 15.08, Tim Goetze wrote:
Steve Harris wrote:
There's no problem if you just wait until no processing is going on
(this is when you'd normally block on the audio deice), and then
switch in the new version.
Obiously, you'll have to remake connections and all that stuff as
well, but that's no different from non-compiling approaches.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
.- M A I A -------------------------------------------------.
| The Multimedia Application Integration Architecture |
`----------------------------> http://www.linuxdj.com/maia -'
--- http://olofson.net --- http://www.reologica.se ---
On Tue, Dec 10, 2002 at 02:03:42 +0100, Tim Goetze
wrote:
No, it really isn't that slow.
SyncModular does a similar trick.
it'd still be interesting to know how the sync problems this
method poses are solved: you cannot rely on executable code
modifications to be atomic. an indirect jump instruction is
not guaranteed to work ok: a pointer on x86 is 32 bits, and
atomic is 24 bits (besides, indirect jumps have ill influence
on the cache). could do this with branching though -- but you
don't want your dsp code interspersed with volatile if()s. Not if it
generates machine code. That way, it could
(theoretically)
in realtime? we'll need everybodies' spare cpu cycles!