Dreaming about novel real-time DSP architectures... bottom up?
I find this discussion and general problem of DSP architectures
suited to parallel computation exciting.
Its something I've pondered while considering a problem in
the implementation layer of procedural audio, which is 'level
of
Here's my current thinking. Based on my current and foreseeable future
use-cases, I see just a few conditions that would play into automatic
prioritization:
- (A) Does the DSP depend on a real-time input?
- (B) Does the DSP factor into a real-time output?
- (C) Does the DSP produce
A few years ago I built a mixing engine for games. Some aspects of the
design sound similar to what you're thinking about.
Every audio frame (I think it was every 256 samples at 48k), the
single-threaded "supervisor" would wake up and scan the graph of audio
objects, figuring out what needed
Haha, Ross, I'm not sure I'll be going *quite* so deep just yet.
My most pressing need is simply to access more processing power than one
callback will give me (without underflow). To that end, I'll be setting up
a signaling system whereby one stream can have "helper threads" that are
notified
Hi Evan,
Greetings from my little cave deep in the multi-core scheduling rabbit
hole! If multi-core is part of the plan, you may find that multicore
scheduling issues dominate the architecture. Here are a couple of
starting points:
Letz, Stephane; Fober, Dominique; Orlarey, Yann; P.Davis,
Hello ---
Some months ago on this list, Ross Bencina remarked about three prevailing
"structures" for DSP systems: Push, pull and *supervised architectures*.
This got some wheels turning, and lately I've been confronted by the need
to squeeze more performance by adding multi-core support to my
