DSP Reverb

I moved this here because we were talking too much shop in the brewery.

My latest project:


The fine-pitched chip you see (well, they're almost all fine-pitched) is a DSPB56366 which is a 120 MHz digital signal processor with a host interface, multiple audio serial ports, and a bunch of internal memory. The two memory chips make up a 512k by 24 bit audio delay memory. The host processor (which you can see in the background) connects to the LCD/VFD, keypad, MIDI ports, level display. I originally started with an MC9S08AC128 but I thought the code was going to be too big and complicated so I changed to a MCF51AC256 which is a 'Coldfire' series part. If you're not familiar with that series, it is a stripped-down version of the 68000. I've seen this family used by Alesis (HD24, ION Q01), so it's not unusual to see it in a musical environment.

[quote author="nickt"]Dumb question Dale - why would you do this with hardware when you could do it in software? No disrespect intended just want to understand the motivation.[/quote]

Practically speaking, it is a software project. The hardware is actually a very minor part. The rest of my studio is basically a hardware/analogue setup but with one 24-track HD recorder and two DA88's. But the other thing about a 'hardware' solution is that I can use 100% of the processor's capabilities for reverb, I don't have to share.

If you look at the computing power of high-end reverbs, it is quite formidable. I don't know how many DSP's the Bricasti uses, but it's quite easy to get 2000 MIPS or even more by hooking up several in parallel. In theory, a PC can do it, but memory bandwidth is an issue. One of the limitations of a PC-style memory system which relies on caching heavily is that long delay lines need to be computed in long bursts. SDRAM prefers to be written to or retrieved by-the-page (usually 256 or 512 samples), where one approach to reverberation - the one I prefer due to simpler algorithms - needs to read and write essentially randomly throughout the memory. In that mode, SDRAM is exceptionally slow. If you are designing your own hardware, you can design a memory system that works quickly and efficiently for your own application. In my case, I use fast SRAM for the reverbs, with an option of SDRAM for bulk delay lines (predelay, echoes).

Also, my day job includes hardware design - I've been designing embedded controllers for almost 20 years (oh my, I'm getting too old) so I think I'm pretty good at it by now; to me it's no big deal.

-Dale

What type of reverb algorithm are you using?

Motorola 68000 CPU and DSP5600x were quite common in audio signal processors of the '80s and '90s. The Eventide products used them.

Very nice. This evolved from what you were talking about in February, right?

[quote author="dale116dot7"][...] memory bandwidth is an issue. [...][/quote]
And then some. The three main criteria I use for shortlisting new contenders for embedded signal processing are memory bandwidth, memory latency and heat. Only when those are dealt with does it make sense to talk MMACs/s or MFLOPS.

What do you use for audio I/O? Digital (AES/SPDIF?ADAT) or codec?

Great project,

JDB.

[quote author="dale116dot7"]...so I changed to a MCF51AC256 which is a 'Coldfire' series part. If you're not familiar with that series, it is a stripped-down version of the 68000. I've seen this family used by Alesis (HD24, ION Q01), so it's not unusual to see it in a musical environment.
[/quote]
And AFAIK , one coldfire is running all control & UI tasks AND generates
all modulation signals on Alesis Andromeda.

[quote author="dale116dot7"]
... I don't know how many DSP's the Bricasti uses...
[/quote]

If I remember correctly, something like 7 blackfins

Great project Dale

cheerz
ypow

Yes, I've been working on these boxes for a while now. The Wavefront AL3201 box works ok, I haven't finished MIDI on it yet, though. I'm building a second one, since the software is done.

I finally decided on the DSP56366, based on its easy instruction set, simple pipelining, and easy and cheap development tools. I'm programming it in assembly code (reverb code is quite easy in assembly).

I've started with the Lexicon plate algorithm (the one published that probably should not have been - it was reverse-engineered from a 224), and a hall algorithm that was published in a paper somewhere, using nested allpasses. I've modelled some of the delay effects loosely around the Lexicon multitap functions on the PCM70 and PCM80. I have not thought about pitch shifting or anything like that yet. I'm also looking at a FDN implementation (the Jot reverb) but I haven't yet done that. I'm not too crazy about the 'Freeverb' algorithm - the lexicon algorithms are quite efficient for the echo density they produce.

This board has a PCM3003 CODEC, however, if I make more boards, I will probably have a CODEC, and probably one of the TI sample rate converters which could be used for a straight receiver, or as a sample rate converter, depending on the system configuration. I think I'd arrange it so that both signals get into the DSP, so for four-channel effects, that would be possible. Another option I thought of was to put an ADAT input/output on the board - you get eight channels in and eight channels out. Then you could do surround processing. Anyways, I started out with this PC board layout and thought of all of these neat features. Then I stopped and told myself to just get this version of the board made and start building.

-Dale

[quote author="dale116dot7"]I've started with the Lexicon plate algorithm (the one published that probably should not have been - it was reverse-engineered from a 224)...[/quote]
HUH????!!!! There is some Lexi algo in public space???

BTW I guess you know 'bout this one
http://mixonline.com/online_extras/blesser-patent.pdf

That damn EMT250 is one remarkable box (well, remarkable algos at least)

cheerz
urosh

Jon Dattorro had a drawing 'in the style of Griesinger' which was reportedly reverse engineered from a 224. Lexicon wasn't particularly happy with that being released. It is a very computationally efficient structure and it sounds good, too. It basically is an adaptation of the Schroeder algorithm, where instead of parallel/series comb/allpass structures, the algorithm is made of only series comb/allpass structures. The 'loop' provides a longer Rt. Essentially it is how you turn a single slapback delay into a multiple number of echoes.

Of course, Lexicon didn't really publish anything quite like that directly. Anyone with an EPROM reader, assembly language hacking skills, and a service manual from a Lexicon 224 or 200, or even a PCM60 or PCM70, could figure it out pretty quickly. Eventide and a host of others have published reverb algorithms in various AES papers. The secret, though, is not just the algorithm, but the tuning of it. The methods used to get those have a lot to do with 'the sound'.

-Dale

[quote author="dale116dot7"]Jon Dattorro had a drawing 'in the style of Griesinger' which was reportedly reverse engineered from a 224. [/quote]
I know 'bout Dattorro algo, but had no idea it is (suposedly) based on
224 plate.

cheerz
urosh

Is that a demo board or you also made it?

I once "tried" to repair my Ursa Major 8x32, it's still has a malfunctioning decay, but It was interesting to see how those old reverbs actually work. I think it's an adaptation of the Moorer reverb, with 6 parallel analogue allpass filters.

Do you use something like labview to test algorythms?

Here's some info that may be useful:

http://www.stanford.edu/~dattorro/research.html

regards, Jack

Yea, I've read all of those. That board is one that I designed and built - not a demo board.

I test algorithms by just writing them and seeing how they work. DSP code isn't really that much harder than the embedded stuff I do as a day job. Initially, I just set up the host so I can independantly change the settings. Once I know how it acts, I write code to set up the various coefficients based on more sensible things like 'RT60' and 'Size'.

[quote author="tony666"]
I once "tried" to repair my Ursa Major 8x32, it's still has a malfunctioning decay, but It was interesting to see how those old reverbs actually work. I think it's an adaptation of the Moorer reverb, with 6 parallel analogue allpass filters.
[/quote]

http://www.sevenwoodsaudio.com/SST282_History.htm

cheerz
urosh

So Dale, could you make a plugin that really sounds like a big Lexi unit and worked with reasonable CPU use in realtime? I think that would sell well, as no plugin I've tried gets anywhere near that sound. I remember you wrote about the particular random memory access of the 480l being something an x86 would struggle with.

[quote author="living sounds"]So Dale, could you make a plugin that really sounds like a big Lexi unit and worked with reasonable CPU use in realtime? I think that would sell well, as no plugin I've tried gets anywhere near that sound. I remember you wrote about the particular random memory access of the 480l being something an x86 would struggle with.[/quote]

The Audio Damage reverence is based upon a Lexicon 200 (perhaps modelled after that datorro paper, don't know)

It would be nice to have some hardware box with algorythms modelled after old Lexicon, EMT250, Ursa Major and Eventide stuff (8 in /out)

Dale, I know you can do that :green:

[quote author="living sounds"]So Dale, could you make a plugin that really sounds like a big Lexi unit and worked with reasonable CPU use in realtime? I think that would sell well, as no plugin I've tried gets anywhere near that sound. I remember you wrote about the particular random memory access of the 480l being something an x86 would struggle with.[/quote]

Well, if you try to code the algorithms in the same manner as the dedicated hardware boxes, then try to run it on a PC, it'll probably tend to choke. In theory, a 'plugin' should be able to mimic a 480L or whatever. There are a few reasons it can be difficult, but not impossible, to do. The memory bandwidth is one, and sharing the processor with an operating system that likes to be a hog is another. But by doing block processing, it should be possible to implement those types of algorithms.

The 480L uses four ARU sets which translate into a measly 25 MIPS of processing performance, and even that is probably too high of an estimate. Many commercially available DSP chips will do it - and then some. A modern Intel or AMD processor should be able to do that without even thinking about it. The harder thing is essentially a 25 MHz random access memory throughput, or 40 ns. With precharge and pipelining and just plain old access time, SDRAM can't do it, so rethinking the algorithms to process blocks of, say, 128 samples at a time, will tend to work better.

The other trick is understanding the reverb algorithms. It takes a lot of effort to reverse engineer reverbs like the 480L and the PCM91. There are multiple processors in there (the 480L has four Z80's and a 68k). You can do it, but you really need to be a good embedded designer to pull that kind of task off. I've gone to a level of about 30% on a PCM70, and it's taken me probably 80 hours of reverse engineering on that box alone. I see the algorithms, but there's so much more there to figure out. I don't know if I want to spend that kind of time reverse engineering things.

I'm also not a plug-in writer, I rarely write things for a PC at all, I'm definitely an embedded system guy - sort of the definition of a 'real programmer'. No operating system to get in the way.

Apologies for the OT but all this DSP-talk got me wondering...
...triggers the question how for instance to position todays 'cheap' hardware boxes (like say TC Electronics' entry level boxes like M-300/G-Sharp/etc) w.r.t. decent native plugins... a little voice somewhere says it might be smart to outsource reverb-tasks to a simple'n'simple but dedicated hardware-box (possibly even integrate it nicely by means of a S/PDIF-link to&from) and let the internal CPU free from this task.

I'm not sure how to rank those more recent DSP-boxes w.r.t. computer-CPU's... (as far as non-convolution reverbs are concerned)... care to spend a few words on it ?

Thanks,

Peter

Thanks alot Dale! If you ever feel like putting the algorithms in a plugin there's surely no shortage of plugin programmers out there who would love to do that.

It's my impression that the people making the early digital stuff were far better in getting good sound than plugin programmers today. Essentially, all the digital reverbs still considered great (EMT, Lexicon, AMS, Quantec) came out in the early 80s, and that was it. Now there are zillions of plugins, but none comes even close. And reverb is not the only example. For instance, even my ancient DX7 sounds a lot better than all the FM plugins. Or the good old Eventide units.
On the other hand, it took years to develop the Bricasti. Maybe plugin designers don't make enough of an effort to realy nail the sound?

Anyway, it's great to be a member of this board and have all that real expertise here!

Thanks!
Gregor

I don't know. After so much work on this one, I can just cry out loud for kits from you. Or maybe you culd offer a limited kit with just the board, the pre-soldered SMD components and the software. That way, you could get some money back from all your work, and all this work wouldn't be just in one or two units (I don't know how many units you are planning on doing for your own use, but just a guess...).

dale116dot7 said:

I moved this here because we were talking too much shop in the brewery.

My latest project:

Click to expand...

I see some blue wires ... it must be real!

-a

rafafredd said:

I don't know. After so much work on this one, I can just cry out loud for kits from you. Or maybe you culd offer a limited kit with just the board, the pre-soldered SMD components and the software. That way, you could get some money back from all your work, and all this work wouldn't be just in one or two units (I don't know how many units you are planning on doing for your own use, but just a guess...).

Click to expand...

I'd be in for a kit for sure! Kept simple, just digital I/0 for instance.