[sdiy] Delays: how?

[Magnus Danielson]

From: Ingo Debus <debus at cityweb.de>
Subject: Re: [sdiy] Delays: how?
Date: Thu, 26 Dec 2002 14:46:57 +0100

> Magnus Danielson wrote:
> > The question then comes if one should vary the sample-rate or if one
> > should change the offset between the read and write counters in the
> > memory.
> 
> Varying the sample rate would require a fast ADC to get a decent delay 
> time range (high sample rate for short delay).

If you want a good quality all the time that is. Varying the sample rate
brings you a myrriad of problems, some which are shared with BBD, but
some that are unique. For instance, not all AD and DAs behave
necessarilly as we expect during changed samplerate conditions. I am
thinking of sigma-delta/noise-shaped converters which adds non-linear
properties to the calculation.

Really, I never said it was a good option, I mearly said it was one way
to solve it.

> I think varying the address offset (between read and write address) to 
> modulate the delay time isn't that bad. There are single samples 
> repeated or skipped when the delay time gets longer/shorter. If the 
> modulation source is, say, a ramp, it becomes effectively a staircase. 
> If this is still to "steppy", just increase the sample rate to make 
> the stair steps finer. Memory chips are cheap.

Indeed. But you have still to understand one of the aspects that I was
hinting on.

> There were digital delays that didn't use different read and write 
> addresses to vary the delay time, but limited the address range 
> instead (i.e. variable reset address for the address counter). This is 
> of course next to useless for delay time modulation, since it only 
> takes effect when the counter wraps around.

Indeed. Also, what you save is basically a counter, a mux and a handfull
of control-logic.

> > The technique that could be used is to run the memorychip as a
> > flexible buffer between two different clock domains (i.e. asynchronously)
> > which is a little more difficult to implement, but is really not that
> > much of a mystery these days (look in for instance the Xilinx appnotes).
> 
> Two different clocks? To get pitch shift effects? Or what would this 
> be good for?

Sorry for speaking digital design lingo... two different clocks does not
necessarilly have to have different frequencies all the time. In digital
design you need to know not only if things are of the same or different
frequency, but you also want to know if things are synchronous or
asynchronous. You can have two clocks which have different frequencies
but is synchronous in relation to each other, which makes design simple.
You can also have two clocks of nominally the same frequency, but which
may vary only slightly in relation to each other. Then those clocks must
be considered to be asynchronous in relation to each other, which can
include synchronous relations under certain periods of operation. As soon
as two clocks are not the same frequency and/or not being synchronous you
consider them to be two separate clocks. The aspects which makes them
different forces you to different amount of work to handle the situation.

Now, you could have a read and a write clock which nominally have the
same frequency, but then you could vary the write clock such that you
changes the phase difference between the clocks, such that the delayed
time vary. This way you could make smooth adjustments of delay on sub-
sample resolution. You can even have it under analogue control.

What you do is that you generate the write clock out of the read clock
using a PLL. The PLL uses the buffer fill level as the phase detector.
The delay CV is then used to compare the reference level, and the output
of that comparision is sent to the loop filter. While this may sound
crude, I know that you can make this become very stable. You get a very
accurate delay control and you also get the pitch-shifting associated
with varying the delay. In all this gives you much of the "feel" of an
analog delay under CV control, but using modern component.
I've build similar stuff before, so I am with comfort of this solution.

You could probably even make it a 24-bit stereo device without much
twisting of an arm.

You also get the benefit of (fairly) stable samplerates, such that
antialiasing filters become trivial and static, yes, pure textbook stuff.

Component count is not expected to be much. Hmm... there's a project!

Cheers,
Magnus