[sdiy] Delays: how?

[Magnus Danielson]

From: Ingo Debus <debus at cityweb.de>
Subject: Re: [sdiy] Delays: how?
Date: Sat, 28 Dec 2002 15:15:20 +0100

Dear Ingo,

> Ah, now I understand. This is really an interesting approach. The more 
> I think about it, the more I like it.

Yes, indeed. Happy that somebody commented it! I feel kind of proud about
it actually! ;O)

> Are there any commercial delays that work this way?

I don't know. I just invented the approach. It seemed "natural" to me,
but then again, who knows, it could be new to the field.

> So read and write sample rates are the same, and independent of the 
> delay time, as long as the delay time is not varied.

Exactly! This means you could be running 48k, 96k or 192k Hz or whatever
preference you have and most of the time you are spot-on!

> If the delay time is varied, i. e. modulated, one of the sample rates
> change, so the read and write pointers move closer together or further
> apart.

Yes. Exactly. The changes would go smoothly, since the clocks are analog
processes.

> The upper and lower limits of the sample frequency would affect the 
> maximum rate of change of delay time, but not the delay time itself. 
> Did I get it right?

Spot on correct.

There is also the issue of how quick changes the A/D and D/As tolerate.

> But if you're using standard (not dual-ported) RAM chips, there has to 
> be some arbitration logic to prevent that the read logic and the write 
> logic tries to access the RAM at the same time. Isn't this quite 
> complicated?

No. You can allways emulate dual-port aspects by multiplexing ports.
Also, in this case you have to watch out since the two ports are not
synchronous, however, that can be handled. If you run the multiplexing
in the write-port speed, then you on average have one read, but can have
zero reads or two reads occasionally. The safe way to acheive that is to
run the memory in triple speed, allowing one write slot and two read
slots. You use a small asynchronous buffer to bridge between the trippled
write clock into the read clock domain, and then synchronous operation
happends in that clock domain. The read pointer is advanced due to the
needs in the asynchronous buffer.

> Also, what you call "buffer fill level" is, as I understand it, the 
> difference between the two address counters. Calculating this 
> difference on the digital side isn't trivial either, because of the 
> two different clocks.

Indeed. However, this problem can also be solved. You could either run
the counters in the same clock-domain, or frequency convert one of the
counters. Recall, even if we run 192 kHz sampling rate and tripple speed
of that we are still in baby-speeds compared to what we have available in
FPGAs, so many different solutions could be created.

I haven't figured out the best way to acheive this, but I know of several
ways to acheive it.

Hmm... maybe one should write a little article about this design... and
maybe we can keep Harry happy for keeping BBDs out of the way! ;O)

Cheers,
Magnus