On Wednesday 11 December 2002 00.05, Steve Harris wrote:
On Tue, Dec 10, 2002 at 10:28:29 +0100, David Olofson
wrote:
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.
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.
The solution in SyncModular is much simpler, theres a big "Compile"
button and when you press it the sound goes away for a second or so
:)
Well, yeah - but I was under the impression that the idea was to
*avoid* that. :-)
Obiously,
you'll have to remake connections and all that stuff as
well, but that's no different from non-compiling approaches.
Well, you dont because the connections are part of the code (at the
lower levels at least).
Yeah. I was rather thinking about connections to the host or "outside
world" - and then there's state data, of course.
I think this is one of the things that makes it
efficient.
Indeed. You can't beat passing data through registers without
copying, and flow control by placement rather than jumping. :-)
//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 ---