[sdiy] Parallel processing clock design question

[jbv]

Magnus Danielson :

> NO! NO! NO!
>
> 48 kHz is a high interrupt frequency. Using interrupt for syncing at that
> rate is a BAD idea. Even 8 kHz is considered high on many micros. The more
> advanced machines, the more crap happends on interrupt before the first
> instruction is executed, and the more stuff you have to do to keep things
> clean.

I see your point but this might not be 100% true.

Here's how I see things : each uC will run a forever loop just
doing nothing (waiting for interrupt signal actually). When
interrupt occurs (at 48KHz), then the real task begins (most of
the time computing the next sample for a set of phase accumulator
osc. or a set of granular reverbs).
The only condition is that the real task should end before the next
interrupt signal (which leaves about 1560 microcycles at 75 MHz,
which is more than enough, especially if some kind of pipelining
has been implemented).
I agree that this is some kind of brute force method, and may be
not the most elegant design, but it might work quite well.
The advantage of this method is that, when interrupt starts, there's no
need to save registers and such, since the main task is doing nothing.
Furthermore, the uC I'm planing to use (the Scenix SX) has a very
short interrupt rersponse time (50 to 60 ns IIRC).

Of course, syncing the uC clock with the 48KHz signal could be
a slightly better solution : since most algorithms (osc banks, filters
banks, reverb banks) will be straightforward loops, the clock could
be a multiple of 48KHz (73.728 MHz for instance), which leaves
exactly 1536 microcycles to compute the next sample. In that case,
the interrupt signal is not needed anymore, but the programer has
to make sure that each algo consist of a loop with EXACTLY
1536 uc...

JB