Yes. The last output of the reverb will occur 79999 samples after the last input, or 1.81 sec after the input stops. Add to that the latency of the processing, I/O buffering, etc. The processing can be speeded up considerable by using partitioned convolution.
On a DSC or DSP you spend more time looking at dissasemblies to see if the compiler generated the instructions you want and less time worrying about interruptions to real time processing.
Doesn't sound like my idea of fun!
One would hope that between the PC, sound card and a suitable buffering system, the PC can go off and do what it wants whenever it wants, within reason. They use PCs in professional recording studios these days, so I'm guessing that they've got it covered.
How are you going to link your audio source to the DSP card? Can you avoid opening a whole new can of worms, worrying about real or imaginary jitter, resampling etc.?
I know of two GPU convolution engines, GPU Impulse Reverb VST | NVidia/ATI GPUs used as DSP for convolution reverb calculation using OpenCL and Reverberate by Liquidsonics using CUDA.
GPUs are really beasts these days. I'm a finishing grad student in lattice QCD. Supercomputers for high energy physics (and everything else I assume) are all based on GPUs now. The cluster here in Frankfurt has about 700 ATI cards in it.
I haven't had a time critical application so I'm still just using my i5 for convolution.
GPUs are really beasts these days. I'm a finishing grad student in lattice QCD. Supercomputers for high energy physics (and everything else I assume) are all based on GPUs now. The cluster here in Frankfurt has about 700 ATI cards in it.
I haven't had a time critical application so I'm still just using my i5 for convolution.
Ceratinly there have not been problems with the PC based UE provided the PC is within the required specifications.
FFT convolution is not the solution to all problems :-(
What is the relation between FFT length and frequency resolution?:
I will stay in time domain.
In the filter case, for each passband I will need to downsample to some apropriate frequency related to upper filter frequency. I am thinking 24 dB per octave filter slope, sampling at 3 octaves above should be ok I guess. Halving 96 kHz I get these frequencies:
2.5k - 20k : 96 kHz
300 - 2.5k : 24 kHz
80 - 300 : 3 kHz
30 - 80 : 750 Hz
Accurate Estimation of Minimum Filter Length for Optimum FIR Digital Filters. Koichi Ichige, Mamoru Iwaki and Rokuya Ishii. Interesting reading on FIR filter length optimization. Filter length is determined by the amount of ripple you can tolerate. How much ripple is acceptable in hifi?
What is the relation between FFT length and frequency resolution?:
I will stay in time domain.
In the filter case, for each passband I will need to downsample to some apropriate frequency related to upper filter frequency. I am thinking 24 dB per octave filter slope, sampling at 3 octaves above should be ok I guess. Halving 96 kHz I get these frequencies:
2.5k - 20k : 96 kHz
300 - 2.5k : 24 kHz
80 - 300 : 3 kHz
30 - 80 : 750 Hz
Accurate Estimation of Minimum Filter Length for Optimum FIR Digital Filters. Koichi Ichige, Mamoru Iwaki and Rokuya Ishii. Interesting reading on FIR filter length optimization. Filter length is determined by the amount of ripple you can tolerate. How much ripple is acceptable in hifi?
Windows (I belive we are talking Microsoft here) has absolutely no realtime support whatsoever. One has to put in a lot of effort make it perform stable in a DSP application.
However, in our world it is acceptable with a few mishaps as long as you don't destroy the speakers.
Personally I will not enjoy listening to a system not knowing exactly what it is doing.
You should add a short FIR to do a brickwall LP at Nyquist nonetheless, to avoid any problem.
That is what Rainer Thaden does in the Four Audio HD2:
http://www.four-audio.com/en/technical-articles/inside-the-hd2.html
http://www.studitech.ru/resque/manuals/fouraudio/HD2-AES32_rev-5.pdf
You can see that when playing with different window functions (and impulse length) in rePhase.
I am totally with you on this, and would not stand any risk for my precious compression drivers... (2450SL+Truextent diaphragms and ET703 tweeters)
I think it is okay to buy several miniSHARC cards ($175 apiece) for such a crossover.
Knowing exactly what is going on is also the reason why I would prefer a direct convolution to a FFT one., even if the later *can* be made as good (good enough) as the former...
Last edited:
what is the MTBF of a eval. board pushed to the limits ?
8 long straight convolutions during hours will be a good test.(under max thermal limit).
a good power supply and fan added should increase lifetime/failure.
IMHO,wise way is to use IIR Xover and a FIR in front of.(or FFT conv. for high FR resolution and low cpu consumption ).
8 long straight convolutions during hours will be a good test.(under max thermal limit).
a good power supply and fan added should increase lifetime/failure.
IMHO,wise way is to use IIR Xover and a FIR in front of.(or FFT conv. for high FR resolution and low cpu consumption ).
Last edited:
Knowing exactly what is going on requires understanding that Fourier transform is gateway between time and frequency domains, theoretically no information is lost.
Losses to math noise are inconsequential next to transducer performance.
All convolution processing uses fundamental math found for numerical methods of producing Fourier transforms.
Losses to math noise are inconsequential next to transducer performance.
All convolution processing uses fundamental math found for numerical methods of producing Fourier transforms.
How do you know how miniDSP (or any other manufacturer) will implement their FFT convolution?
I have had bad (albeit very limited) experiences with SIR, so I would prefer to stay with a direct, straight forward convolution if possible (even if that implies using several miniSHARCs, if they do not implement downsampling), and this will also give the shortest processing time for a given impulse length.
I have had bad (albeit very limited) experiences with SIR, so I would prefer to stay with a direct, straight forward convolution if possible (even if that implies using several miniSHARCs, if they do not implement downsampling), and this will also give the shortest processing time for a given impulse length.
i think too.
during listening,with a "flat" IR loaded in the convlover,switching bypass has no effect on quality sound perceived.
loopback sound card measurement shows no more THD and IMD.(also partitioned FFT).
that's why i don't understand why direct convolution is better (except a huge cpu load+power supply+EMI).
a challenge to extract the best of a standalone DSP ?
Last edited:
i've tried:
SIR v1.011
VSTconvolver
LeCab2 (till 65000 taps )
a very short one (the given impulse)a capture from the excellent book linked before (about DSP)
chapter 18.3
may a 200/300 taps IR in a direct engine is little faster than FFT engine.
i go to try a direct conv. to compare process time.
I understand the fear of PC based crossovers (I've had the problem), but the Behringer? Never had one output what it was not supposed to, ever. You can set it wrong, but you can do that with a DSP board.These will not come close to any PCs or Behringers
What's your experience?
Thierry, I am talking about real elapsed time (delay), not CPU time.
In direct convolution with a hardware solution like the openDRC and a DAC, you can expect only a few ms of delay in addition to the "normal" delay implied by the impulse (depending on the position of the peak within the impulse).
A PC would already add some buffering delay for the soundcard, and some more if FFT is used...
In direct convolution with a hardware solution like the openDRC and a DAC, you can expect only a few ms of delay in addition to the "normal" delay implied by the impulse (depending on the position of the peak within the impulse).
A PC would already add some buffering delay for the soundcard, and some more if FFT is used...