KVR Audio

m0nty · Post by **m0nty** » Mon Oct 23, 2006 6:36 pm

Hi everybody

What I want to do is to take the recorded impulse response of a soundboard, but instead of doing convolution (I can't have fft-conv, because the delay involved with that is not an option), I want to filter the incoming signal with a transfer function which approximates the response.

I read in past forum posts ( http://www.kvraudio.com/forum/viewtopic.php?p=1823130 ) to look at the Prony algorithm, but I couldn't find any in-depth explanation, so I was wondering
- any link?
- other options?

thanks in advance
Nicola

jupiter8 · Post by **jupiter8** » Mon Oct 23, 2006 6:46 pm

You can do convolution without FFT. It'll be CPU heavy though but if the impulse is short it might not be too bad.

m0nty · Post by **m0nty** » Mon Oct 23, 2006 7:00 pm

I thought about that, but ~7 seconds is not very short ...

I could make the i.r. shorter, but even 0.7 sec would be way too much (30870 multiply+add for each audio cycle at 44.1kHz).
Nicola

jupiter8 · Post by **jupiter8** » Mon Oct 23, 2006 7:17 pm

CPU heavy indeed. But is'nt this way quite simple to implement in SSE ? I've just started with it so i'm not sure. May still be to heavy though.

Zaphod (giancarlo) · Post by **Zaphod (giancarlo)** » Tue Oct 24, 2006 7:31 am

Using assembler&SSE2 you could achieve more or less 10000 samples (mono) using direct convolution on a Centrino 2.2 Ghz. Don't expect more...

If you need real-time, try the hybrid approach patented by Lake Tec., both direct&fft convolution mixed. I haven't read exacly their patent, but it's easy to guess: you use direct convolution for few samples (not cpu expensive if they are few), and append fft convolution (wich needs bigger buffers) just immediatly after.

bogac · Post by **bogac** » Tue Oct 24, 2006 12:22 pm

m0nty wrote:Hi everybody

What I want to do is to take the recorded impulse response of a soundboard, but instead of doing convolution (I can't have fft-conv, because the delay involved with that is not an option), I want to filter the incoming signal with a transfer function which approximates the response.

I read in past forum posts ( http://www.kvraudio.com/forum/viewtopic.php?p=1823130 ) to look at the Prony algorithm, but I couldn't find any in-depth explanation, so I was wondering
- any link?
- other options?

thanks in advance
Nicola

Hi Nicola,

An in-depth explanation of the Prony algorithm can be found on page 226 of "Digital Filter Design", T.W. Parks and C.S. Burrus, John Wiley and Sons, 1987.

The hybrid zero-delay convolution algorithm, which is patented by Lake Technology is clearly described by Gardner:

W. G. Gardner, "Efficient convolution without input-output
delay", J.AES vol. 43, n. 3, 1995 March, pp. 127-136.

which is basically real-time non-uniform partitioned FFT convolution. The uniform partioned FFT convolution is probably patent free, and it is clearly described by:

A. Torger, A. Farina, "Real-Time Partitioned Convolution for
Ambiophonics Surround Sound", 2001 IEEE Workshop on
Applications of Signal Processing to Audio and Acoustics, New
Paltz, New York, 21-24 October 2001.
http://www.angelofarina.it/Public/Paper ... nk2001.PDF

and

E. Armelloni, C. Giottoli, A. Farina, "Implementation of Real-Time Partitioned Convolution on a DSP Board", 2003 IEEE Workshop on Applications of Signal Processing to Audio and Acoustics, October 19-22, 2003, New Paltz, NY
http://www.angelofarina.it/Public/Paper ... nk2003.pdf

Considering your requirements, I guess this approach is most suited to your application.

m0nty · Post by **m0nty** » Tue Oct 24, 2006 2:55 pm

thanks for the replies
especially to bogac, very detailed
i'll look into those and let you know

Zaphod (giancarlo) · Post by **Zaphod (giancarlo)** » Tue Oct 24, 2006 3:13 pm

me not?!?
Ok, I'm joking

tony tony chopper · Post by **tony tony chopper** » Tue Oct 24, 2006 3:44 pm

the other problem with FFT is that its CPU usage isn't spread ideally for buffered audio. I mean, if the latency is short, you may be asked to process short buffers, so, buffering audio till your FFT buffer is filled, and then process it, causing spikes in CPU usage.

So basically, an algo can be 'realtime', meaning CPU usage <100%, but still not realtime because of uneven CPU usage causing underruns. So you'll have to use a side thread processing your FFT in the background, but I'm afraid this causes even more delay, since you won't be able to use the results, at the time you've filled your FFT buffer, until the side thread has finished.

m0nty · Post by **m0nty** » Tue Oct 24, 2006 7:15 pm

Well, I also thought about the fft problem of cpu spikes ...
Anyway, I just want to point out that I don't need an EXACT aproximation of the impulse response, I just want the filter I create to sound like the impulse response.
So I think I'll also look for some general reverberation algorithm, and then manually "tune" it to fit a particular sound.
But it would be cool if I could let the user load a wav file with the impulse response of a particular soundboard, and then build a filter of an arbitrary order which approximates it.
I may have found something useful here, but I'm just checking it out: http://www.acoustics.hut.fi/research/cat/dsp/
So, I'm still looking for help ...
Thanks (to Zaphod too

)
Nicola

jupiter8 · Post by **jupiter8** » Tue Oct 24, 2006 7:27 pm

How about direct convolution where you discard samples that are below a certain threshold ? I've never done it myself but in theory that would sound pretty close would'nt it ? At least that's what i'm thinking.

That way you could lower the CPU load a lot depending on how "thick" the IR is. Couple this with SSE2 optimization,it might just do the trick.

And you're welcome.

larm · Post by **larm** » Tue Oct 24, 2006 7:51 pm

Does SIR use fft convolution? (because of the latency?)

Zaphod (giancarlo) · Post by **Zaphod (giancarlo)** » Wed Oct 25, 2006 8:14 am

tony tony chopper wrote:the other problem with FFT is that its CPU usage isn't spread ideally for buffered audio. I mean, if the latency is short, you may be asked to process short buffers, so, buffering audio till your FFT buffer is filled, and then process it, causing spikes in CPU usage.

So basically, an algo can be 'realtime', meaning CPU usage <100%, but still not realtime because of uneven CPU usage causing underruns. So you'll have to use a side thread processing your FFT in the background, but I'm afraid this causes even more delay, since you won't be able to use the results, at the time you've filled your FFT buffer, until the side thread has finished.

really true, tony. I avoided to write this, because I thought there were better solutions. I solved this problem exactly in the way you have described, using a different thread. But I don't suggest this solution, is very hard to implement, there are a lot of side effects and complexity grows up quickly.
The trouble is synchronization, semaphoring, additional latencies and really depends on the asio buffers length used, so tuning could be really an hard task.
There is an interesting side effect too. Some hosts (I haven't tried your FL anyway) calculate performaces reading "how much delay" there is for a "process" call. If you have a separate thread probably you'll return a result "immediatly" if your buffer is not filled yet. So for example cubase could see a 0% cpu even if plug is wasting 30%. The workaroud is to spread the "sleep" for the process call, so you need to calculate "how much cpu" the separate thread is using. As you know, this is not simple. Think to multiple-processor troubles with RDTSC, tickercount troubles for some Via chipset, troubles for using the same windows api inside a different threads and so on.
Having implemented "cpu-meter" inside FL, probably you know perfectly how hard this is this (apparently) simple task.

Zaphod (giancarlo) · Post by **Zaphod (giancarlo)** » Wed Oct 25, 2006 8:15 am

duplicated, sorry

Zaphod (giancarlo) · Post by **Zaphod (giancarlo)** » Wed Oct 25, 2006 8:20 am

About truncating:

And what about reverbs? 10 ms is not enought for a "long hall", sure...
what about eqs with narrows q?

fitting an impulse response - prony algorithm