Build in uSecs of DELAY into DAC??

[bear]

Ok,

I have seen a university project that did this, and I guess the cheapo portable CD players actually do it (15-60 secs of anti-skip), but does anyone have any references or citations, or suggestions about how to build in a specific (fixed if that is easiest) amount of straight up delay into the digital stream of a DAC. Assume you can modify or build a known DAC circuit that is suitable.

The simple idea is that I'd like to delay (for example) an HF array a fixed amount of time - external digital delays (as used in a typical PA/SR system) are not going to be a suitable "high-end" solution here...

_-_-bear

[Petter]

I can't really see what is wrong with something like a Behringer DCX2496 which does this.

You can easily build a delay circuit for S/PDIF or even easier (but more delay parts) the MCLK / BCLK / SDATA / "L/RCLK" - you need 3 delays and for the latter and you could clock it with BCLK - you can get logic chips which have multiple delay elements and serial IO ports (some even programmable) this or do a round-robin RAM based variant. The former obviously requires an input receiver etc.

You could also do the same kind of thing using a computer.

You probably also owe it to yourself to search for [Erland Unruh DAC] for a really cool implementation of a digitally controlled delay buffer for input receiving.

Also, PS Audio did some interesting things in their older products - Ultralink or Audiolink or something like that. Genesis Digital Lens was also a Jitter attenuator courtesy of digital delay.

[bear]

Sorry, my title should have read mSecs... not uSecs...

But I'll look for that citation...

The Behringer products are nice enough, but generally not terribly good to listen to, have higher than optimal noise level, use all tiny, tiny surface mount stuff, and a very tough to get into for mods (even changing out opamps) unless you have a SMD station and a microscope. Other than that they're very cost effective. Also, afaik, no schematics are available. (and, I think everything passes through a DSP chip or two, which is a black box as far as what it is doing or not...)

I'm looking for ultimate quality above all else.

And being a digital ignoramus, I need genuine information and insight into this sort of implementation. <---

But, does anyone know of a site with the Behringer schematics?

_-_-bear

[macboy]

How much of a delay do you need? You could try to use a large FIFO chip (search Digi-key for "FIFO"). If you just need a few ms of delay then you could use the data, and LRclock lines as the data in/out of a large FIFO and the bitclock to clock it. If you need more than that, you will have to parallelize the datastreem and use the LRclock to clock the samples in/out of the FIFO.

[bear]

Originally posted by macboy
How much of a delay do you need? You could try to use a large FIFO chip (search Digi-key for "FIFO"). If you just need a few ms of delay then you could use the data, and LRclock lines as the data in/out of a large FIFO and the bitclock to clock it. If you need more than that, you will have to parallelize the datastreem and use the LRclock to clock the samples in/out of the FIFO.

Unsure at the moment, but likely in the 10 mSec range, iirc.

The idea is to time delay the tweeter vs. mids where there is a physical distance between the two...

...being able to set up the amount of the delay, even if that is more or less in hardware, is essential. A random amount of delay won't do the trick.

So, how would this work with a FIFO?

I wonder though, if you delay the data, regardless of where it is in the data stream, if the bitclock is sync'd to the input signal then once the source ends, the bitclock goes off sync? Hmmm... been many years since I last looked at the guts of a DAC in detail, guess that shows...

_-_-bear

[pinkmouse]

bear,

Where is this signal coming from? If it's coming straight from a cdp, then it's going to be full range. If it's coming from a crossover or computer, then surely that has delay options? I don't understand

[macboy]

Originally posted by bear
Unsure at the moment, but likely in the 10 mSec range, iirc.

The idea is to time delay the tweeter vs. mids where there is a physical distance between the two...

...being able to set up the amount of the delay, even if that is more or less in hardware, is essential. A random amount of delay won't do the trick.

So, how would this work with a FIFO?

So if you wanted to delay the serial datastream, then you would probably need about a 32K deep FIFO, since the bitclock would be around 2.82 MHz for CD if I'm not mistaken (and I certainly could be). A 32K FIFO would give you up to 32768/2.822M = 11.6 ms delay maximum. If you need more, you need a bigger device. Luckily there isn't much price difference; they are all expensive . Since the delay is dependant on clock frequency, you may need to detect the difference between 48 kHz and 44.1 kHz inputs, unless you know you'll only ever use 44.1.

The TI SN74V263/273/283/293 FIFOs have a programmable almost-full flag. This is an output pin which indicates that a user-specified threshold has been surpassesd. At this point, you would enable the output clock. This would be a duplicate of the input bitclock, thereby emptying the FIFO at exactly the same rate as you are filling it. The actual delay is determined by the threshold that you program for the almost-full flag.

I wonder though, if you delay the data, regardless of where it is in the data stream, if the bitclock is sync'd to the input signal then once the source ends, the bitclock goes off sync? Hmmm... been many years since I last looked at the guts of a DAC in detail, guess that shows...

Once the source ends, the output clock will stop too, since it is the same clock (you've simply started the output clock a few ms later to create delay). This would result in a few ms of audio getting 'stuck' in the FIFO. You wouldn't know the difference, until a valid clock starts up again and you get a brief blip of old audio before the new audio. So maybe you could build a clock loss detection circuit (like a timer that is reset on each rising clock edge... no clock edge and the timer expires) which would reset the FIFO to get it ready for new data.

[rfbrw]

The simplest solution for a fixed delay in a source synchronous setup is a large shift register implemented in a CPLD or a FPGA.

[hermanv]

I understand that proffesional audio uses delay circuits to equalize arrival times from speakers in large auditoriums.

Perhaps a search for such a device will reveal a design.

I was once asked to design such a device but the project only got as far as a block diagram.

It was as follows:

1. A clock running at 48KHz, in this case maybe 44.1KHz is more appropriate. The clock ran two counters.
2. An A to D feeding a 16 bit wide RAM array clocked by counter 1
3. A DIP switch that would preload counter 2 every time counter 1 overflowed.
4. The RAM data at counter 2 address fed a D to A to convert it all back to analog.

The RAM was of course arranged to be a circular buffer with new data overwriting old data. 65K words would provide about a second and a half of maximum delay. 65K words requires a 16 bit counter, you can scale as needed for different maximum delays.

If you don't use dual port RAM then double the clock and write/read on alternating cycles and divide by 2 for the counters.

You can use cheap DRAM because this scheme automatically refreshes the RAM without needing seperate RAS/CAS cycles.

[gmarsh]

Originally posted by rfbrw
The simplest solution for a fixed delay in a source synchronous setup is a large shift register implemented in a CPLD or a FPGA.

You need a lot of memory though... a typical 64-gate CPLD may only provide 1 or 2 samples of delay on 32/16 bit audio, and a FPGA which has enough delay to get tens of ms of delay isn't going to be cheap, and it's probably going to be a fine pitch SMT / separate-low-core-voltage type of chip.

10msec of delay requires 1764 bytes @ 44.1KHz 16-bit stereo... a 30F4013 dsPIC microcontroller has 2048 bytes of data RAM and a codec interface which supports I2S, and it's a 'nice' 5V-powered 40-pin DIP. As long as you don't increase the sample rate or the delay, you might be able to do it using only this chip.

If the 2048 bytes of RAM isn't enough, you could probably hook up a 62256-style SRAM chip to the PIC with little or no additional logic.