I know that reverbs are normally built with all-pass and/or comb filters in various combinations. Are there topologies that are more CPU-efficient, or more realistic? I'm interested in small room emulation, but I need to keep up in real-time, and processing power may be limited. Obviously many common algorithms are just refinements of the the old Schroder algorithm, but that's a primitive and metallic sound. There must be efficient modern algorithms that solve those problems. Any recommendations?
Anatomy of a reverb algorithm
Started by ●September 14, 2016
Reply by ●September 14, 20162016-09-14
On Wed, 14 Sep 2016 09:54:21 -0400, Max wrote:> I know that reverbs are normally built with all-pass and/or comb filters > in various combinations. Are there topologies that are more > CPU-efficient, or more realistic? I'm interested in small room > emulation, but I need to keep up in real-time, and processing power may > be limited. > > Obviously many common algorithms are just refinements of the the old > Schroder algorithm, but that's a primitive and metallic sound. There > must be efficient modern algorithms that solve those problems. Any > recommendations?AFAIK, comb filters are pretty light on CPU power -- it's a delay with a gain and maybe some feedback. The delay can be implemented by a as- humongous-as-necessary ring buffer, and the taps themselves only involve a few values. But -- I don't do audio, so I should probably keep my mouth shut. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
Reply by ●September 14, 20162016-09-14
Tim Wescott <tim@seemywebsite.com> wrote:>On Wed, 14 Sep 2016 09:54:21 -0400, Max wrote:>> I know that reverbs are normally built with all-pass and/or comb filters >> in various combinations. Are there topologies that are more >> CPU-efficient, or more realistic? I'm interested in small room >> emulation, but I need to keep up in real-time, and processing power may >> be limited.>> Obviously many common algorithms are just refinements of the the old >> Schroder algorithm, but that's a primitive and metallic sound. There >> must be efficient modern algorithms that solve those problems. Any >> recommendations?>AFAIK, comb filters are pretty light on CPU power -- it's a delay with a >gain and maybe some feedback. The delay can be implemented by a as- >humongous-as-necessary ring buffer, and the taps themselves only involve >a few values.>But -- I don't do audio, so I should probably keep my mouth shut.Reverbs are one of the lowest-cost audio effects to implement, and for this reason were one of the first commercial applications of DSP for audio. A Schroeder algorithm should not have a metallic sound, at least not a very prominent metallic sound, if the parameters are selected properly. Steve
Reply by ●September 14, 20162016-09-14
Max wrote:> I know that reverbs are normally built with all-pass and/or comb > filters in various combinations. Are there topologies that are more > CPU-efficient, or more realistic? I'm interested in small room > emulation, but I need to keep up in real-time, and processing power > may be limited. > > Obviously many common algorithms are just refinements of the the old > Schroder algorithm, but that's a primitive and metallic sound. There > must be efficient modern algorithms that solve those problems. Any > recommendations? >Effectively, all reverbs are convolutions of some sort. A "metallic" reverb can be addressed by experimenting with filtering of the response vector. But it really comes down to "more is better", at least to a point. Pure comb filters have that "garden hose" flavor. I have and use the Waves IR convolution reverb, and this old machine ( 2012 vintage i5 dual-core 3.02 GHz) keeps up just fine. It'll consume, say, 2-5% of this thing. This stopped me from implementing one as a VST myself. I was able to get a severely discounted price on the Waves Gold Bundle. Plan C was a physical rackmount reverb device with S/PDIF I/O. I may do that anyway. Let's just say that the build-vs-buy proposition has changed over the years. FAIR USE STYLE IP WARNING HERE! Realtime actual convolution is probably using some sort of proprietary arrangement to keep the delay down. Here's the William G. Gardner paper. I dunno if you can just swipe the algo. from it or not, but it should give you an idea: http://alumni.media.mit.edu/~adamb/docs/ConvolutionPaper.pdf And there's a demo that's ... pretty poorly executed ( but understandably so ) , but it's an interesting project: https://www.youtube.com/watch?v=0Ebnue1a4vc -- Les Cargill
Reply by ●September 14, 20162016-09-14
On Wednesday, September 14, 2016 at 2:10:45 PM UTC-4, Steve Pope wrote:> Tim Wescott <tim@seemywebsite.com> wrote: > > >On Wed, 14 Sep 2016 09:54:21 -0400, Max wrote: > > >> I know that reverbs are normally built with all-pass and/or comb filters > >> in various combinations. Are there topologies that are more > >> CPU-efficient, or more realistic? I'm interested in small room > >> emulation, but I need to keep up in real-time, and processing power may > >> be limited. > > >> Obviously many common algorithms are just refinements of the the old > >> Schroder algorithm, but that's a primitive and metallic sound. There > >> must be efficient modern algorithms that solve those problems. Any > >> recommendations? > > >AFAIK, comb filters are pretty light on CPU power -- it's a delay with a > >gain and maybe some feedback. The delay can be implemented by a as- > >humongous-as-necessary ring buffer, and the taps themselves only involve > >a few values. > > >But -- I don't do audio, so I should probably keep my mouth shut. > > Reverbs are one of the lowest-cost audio effects to implement, and > for this reason were one of the first commercial applications of > DSP for audio. > > A Schroeder algorithm should not have a metallic sound, at least > not a very prominent metallic sound, if the parameters are selected > properly. >a good reverb is not all that inexpensive to implement. you're not gonna get a lotta dispersion with just a couple APFs. you need several. and then to keep the room modes at bay, you might need to slowly move the taps on a couple of the delays. besides the Schroeder model, there are models proposed by Jean-Marc Jot and Bill Gardner. a reasonable looking paper is at http://freeverb3vst.osdn.jp/doc/matlab_reverb.pdf with any of these, if the room gets small, while keeping the RT60 at a constant value, the 'verb will start sounding metallic. at least that's how it sounded to me. r b-j
Reply by ●September 15, 20162016-09-15
> > Here's the William G. Gardner paper. I dunno if you can just swipe the > algo. from it or not, but it should give you an idea: > > http://alumni.media.mit.edu/~adamb/docs/ConvolutionPaper.pdf >Sorry for pulling this a little off-topic, but I have a question for people who know more IP law than I do: under what conditions would it not be okay to use an algorithm that was published 23 years ago? -Ethan
Reply by ●September 15, 20162016-09-15
On Thu, 15 Sep 2016 07:25:46 -0700 (PDT), ethan@polyspectral.com wrote:>> >> Here's the William G. Gardner paper. I dunno if you can just swipe the >> algo. from it or not, but it should give you an idea: >> >> http://alumni.media.mit.edu/~adamb/docs/ConvolutionPaper.pdf >> > >Sorry for pulling this a little off-topic, but I have a question for people who know more IP law than I do: under what conditions would it not be okay to use an algorithm that was published 23 years ago? > >-EthanThere'd be very few conditions under which you couldn't use that. Any patent should have expired, and that'd be the primary barrier to use.
Reply by ●September 16, 20162016-09-16
On Thursday, September 15, 2016 at 10:25:51 AM UTC-4, et...@polyspectral.com wrote:> > > > Here's the William G. Gardner paper. I dunno if you can just swipe the > > algo. from it or not, but it should give you an idea: > > > > http://alumni.media.mit.edu/~adamb/docs/ConvolutionPaper.pdf > > > > Sorry for pulling this a little off-topic, but I have a question for people who know more IP law than I do: under what conditions would it not be okay to use an algorithm that was published 23 years ago? >i ain't a lawyer, but in some sense we are all ethicists. patents last for only 17 years. on top of that Gardner was not the first to patent this, it was Lake DSP. and now the patent is expired. i really think if it was not "okay" to use it, it would be proscribed or prohibited in some way and that is explicitly not the case after the patent is expired. r b-j
Reply by ●September 16, 20162016-09-16
On Wed, 14 Sep 2016 14:41:58 -0500, Les Cargill <lcargill99@comcast.com> wrote:>Max wrote: >> I know that reverbs are normally built with all-pass and/or comb >> filters in various combinations. Are there topologies that are more >> CPU-efficient, or more realistic? I'm interested in small room >> emulation, but I need to keep up in real-time, and processing power >> may be limited. >> >> Obviously many common algorithms are just refinements of the the old >> Schroder algorithm, but that's a primitive and metallic sound. There >> must be efficient modern algorithms that solve those problems. Any >> recommendations? >> > > >Effectively, all reverbs are convolutions of some sort.Purely convolutional reverbs are fairly CPU intensive. That's why I was looking at 'modeling' algorithms, which use allpass and/or comb filters.>A "metallic" reverb can be addressed by experimenting with filtering of >the response vector. But it really comes down to "more is better", at >least to a point. Pure comb filters have that "garden hose" flavor.I have a feeling that comb filters don't get as much love as they once did with the Schrodinger algorithm.>I have and use the Waves IR convolution reverb, and this old machine ( >2012 vintage i5 dual-core 3.02 GHz) keeps up just fine. It'll consume, >say, 2-5% of this thing.That's pretty good. I wonder if they doing some tricks to minimize the time-consuming convolutional steps.>This stopped me from implementing one as a VST myself. I was able to get >a severely discounted price on the Waves Gold Bundle. Plan C was a >physical rackmount reverb device with S/PDIF I/O. I may do that anyway. >Let's just say that the build-vs-buy proposition has changed over the >years.I still love my Lexicons.>FAIR USE STYLE IP WARNING HERE! > >Realtime actual convolution is probably using some sort of proprietary >arrangement to keep the delay down. > >Here's the William G. Gardner paper. I dunno if you can just swipe the >algo. from it or not, but it should give you an idea: > >http://alumni.media.mit.edu/~adamb/docs/ConvolutionPaper.pdf > >And there's a demo that's ... pretty poorly executed ( but >understandably so ) , but it's an interesting project: > >https://www.youtube.com/watch?v=0Ebnue1a4vcThanks, that was pretty cool. At least reassuring to see reverb running on a Beaglebone.
Reply by ●September 16, 20162016-09-16
On Wed, 14 Sep 2016 17:28:39 -0700 (PDT), robert bristow-johnson <rbj@audioimagination.com> wrote:>On Wednesday, September 14, 2016 at 2:10:45 PM UTC-4, Steve Pope wrote: >> Tim Wescott <tim@seemywebsite.com> wrote: >> >> >On Wed, 14 Sep 2016 09:54:21 -0400, Max wrote: >> >> >> I know that reverbs are normally built with all-pass and/or comb filters >> >> in various combinations. Are there topologies that are more >> >> CPU-efficient, or more realistic? I'm interested in small room >> >> emulation, but I need to keep up in real-time, and processing power may >> >> be limited. >> >> >> Obviously many common algorithms are just refinements of the the old >> >> Schroder algorithm, but that's a primitive and metallic sound. There >> >> must be efficient modern algorithms that solve those problems. Any >> >> recommendations? >> >> >AFAIK, comb filters are pretty light on CPU power -- it's a delay with a >> >gain and maybe some feedback. The delay can be implemented by a as- >> >humongous-as-necessary ring buffer, and the taps themselves only involve >> >a few values. >> >> >But -- I don't do audio, so I should probably keep my mouth shut. >> >> Reverbs are one of the lowest-cost audio effects to implement, and >> for this reason were one of the first commercial applications of >> DSP for audio. >> >> A Schroeder algorithm should not have a metallic sound, at least >> not a very prominent metallic sound, if the parameters are selected >> properly. >> > >a good reverb is not all that inexpensive to implement. you're not gonna get a lotta dispersion with just a couple APFs. you need several. and then to keep the room modes at bay, you might need to slowly move the taps on a couple of the delays. > >besides the Schroeder model, there are models proposed by Jean-Marc Jot and Bill Gardner. a reasonable looking paper is at > > http://freeverb3vst.osdn.jp/doc/matlab_reverb.pdf > >with any of these, if the room gets small, while keeping the RT60 at a constant value, the 'verb will start sounding metallic. at least that's how it sounded to me. > >r b-jHi Robert, I know you've worked with these, so I'm glad that you checked in. It seems that more modern algorithms are being used for dispersion, and other effects that are not directly covered by simpler all-pass nets. Enzo De Sena,'s paper discusses digital waveguide nets (DWNs) and scattering delay networks (SDN's). I have waded thru all of those yet, but I'm not sure of the nuance. I got the impression that those are the approaches used in newer reverbs.
