what Brad Smith points out (that at least 1 sample delay is necessary
for feedback) is true for any discrete-time processing alg. and we know
that if "block processing" or "chunk processing" (whatever you wanna
call the technique) would require a minimum delay of BLOCK_SIZE samples
for any signal that is fed back. for forward signals, you can execute
the block processing for operations chronologically in same order of the
signal path and incur no additional delay.
Tom, the point that Didier makes is that you can elegantly amortize
overhead in an algorithm over all of the samples of the block size. fir
instance, suppose that there was a cascade of biquad filters in the
loop. it is more efficient to load up your registers with states and
pointers once, filter the BLOCK_SIZE samples and store that in another
allocated block, then store the states and pointers once. not that
anyone codes for the 56K anymore, but because it has so few registers,
you might not want to load the states, process one measly sample, and
then save all the states.
but for most algs with feedback built in, i think having to put up with
more than one sample delay in feedback is too much to ask. except maybe
for some kinda reverb feedback, since the delays may be much longer than
the block size.
even after looking at his code, i can't really figure out what,
precisely is the operator structure. exactly where the feedback is. i
cannot identify exactly what that array called "bufferp[]" is.
r b-j
On 9/12/11 4:11 PM, Tom Wiltshire wrote:
I disagree, Didier. It's definitely not heresy in principle. In practice, it
depends what platform you're on, but I've done it in dsPIC assembly and you can
get it nearly as fast, as fast, or faster. In that case it depends on the
arrangement of the variables in memory and on efficient use of pointers. YMMV.
Anyway, as you say, he's got no choice, so he'd better try and do it as
efficiently as Java lets him. If there's any heresy, it's probably using Java
for audio processing! ;)
T.
On 12 Sep 2011, at 19:41, Didier Dambrin wrote:
IMHO it's an heresy to do big sample-by-sample loops (but for FM with feedback
you indeed have no other choice), poor use of registers, no use of SIMD,
possibly bad caching.. all the ingredients to be several times slower
As others have said, it shouldn't be more expensive.
Assume a buffer size of eight samples:
Instead of doing A eight times, then B eight times, then C eight times, etc,
you do ABCDEFG, ABCDEFG, etc, eight times.
The amount of computation required is the same or about the same, depending on
the efficiencies of the particular platform.
Now I get why the block size is an issue, and you definitely need to reduce the
feedback path to make it as short as possible - at least, if you're trying to
get 'classic' FM synthesis. Sample rate is an issue here too - a one sample
delay is much less significant if the sample rate is 192KHz than if it's
44.1KHz.
Good luck with it,
Tom
On 12 Sep 2011, at 16:04, Andre Michelle wrote:
I guess, that's it and it makes sense now to me.
This can make FM synthesis quite cpu expensive however. Everything must be
included into a big for-loop.
Thanks.
--
aM
On Sep 12, 2011, at 4:56 PM, Brad Smith wrote:
I always understood FM feedback to require a 1 sample delay. The
output of the current sample must affect the output of the next
sample. If you put, say, a 64 sample delay, it is like you are running
64 delayed feedback loops in parallel, each of them unrelated, and
there won't be any coherence between them (probably it just turns into
white noise once the feedback gets going).
I think this precludes being able to buffer individual operator
outputs, though; you need to calculate the whole chain on each sample
to produce the feedback value needed for the next sample.
-- Brad Smith
--
r b-j r...@audioimagination.com
"Imagination is more important than knowledge."
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp
links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp
