From your FAQ: "FIR implemented using 32 bit fixed point arithmetic with a theoretical resolution of 20 bits."
Paavo, are you saying that the FIR taps are only 20bits deep? Please eleborate.
Why not use 32bit float or better yet, 64 bit double floats?
Jim
FIR precision
FIR precision
Jim,
No, not at all. The issue is that the FIR is implemented using fast convolution via a FFT's rather than the direct form implementation.
Direct form implementation would give you a resolution close to 32 bits but would be impossible to implement in real time because the number of numberical operations required per output sample is far too large.
To make it real time requires the use of fast convolution but because the FFT's are fixed point FFT's there is a signal to noise degradation arising from the inherent truncation.
Why not use 32 bit float? Simply because 32 bit float implementation would be at least a factor of 4 times slower than the fixed point implementation and possible more. This has the effect of restricting the range of machines that you could run the software on. For example, you could forget about running it on anything less than a 1.5GHz machine.
It comes down to a value judgement of whether it is better to have speed efficiency or precision and what the optimum trade off is. Personally I think the status quo is more than adequate. I certainly cannot hear any noise that is introduced by HarBal and would definitely be interested to note if you could. From a pragmatic point of view, if your recording real instruments then the noise introduced by the analog sources will far outweigh anything that HarBal might add (Mic self noise etc).
At some stage in the future I may re-implement the DSP side as 64 bit fixed point though the urgency is not there so It wont be happening soon.
Regards,
Paavo.
No, not at all. The issue is that the FIR is implemented using fast convolution via a FFT's rather than the direct form implementation.
Direct form implementation would give you a resolution close to 32 bits but would be impossible to implement in real time because the number of numberical operations required per output sample is far too large.
To make it real time requires the use of fast convolution but because the FFT's are fixed point FFT's there is a signal to noise degradation arising from the inherent truncation.
Why not use 32 bit float? Simply because 32 bit float implementation would be at least a factor of 4 times slower than the fixed point implementation and possible more. This has the effect of restricting the range of machines that you could run the software on. For example, you could forget about running it on anything less than a 1.5GHz machine.
It comes down to a value judgement of whether it is better to have speed efficiency or precision and what the optimum trade off is. Personally I think the status quo is more than adequate. I certainly cannot hear any noise that is introduced by HarBal and would definitely be interested to note if you could. From a pragmatic point of view, if your recording real instruments then the noise introduced by the analog sources will far outweigh anything that HarBal might add (Mic self noise etc).
At some stage in the future I may re-implement the DSP side as 64 bit fixed point though the urgency is not there so It wont be happening soon.
Regards,
Paavo.
-
Terpsichore
FIR precision
Paavo,
Thanks for the clarification. I don't think I can hear any degradation or added noise either, but I've not really dug as deep into this as I'd like.
I understand your argument, and do understand what FFT based convolution is. However, your processing power estimates don't match my experience using Sonic Foundry's Acoustic Mirror. It uses FFT based convolution using the overlap and add method, since the impulse responses to be convolved can be quite long. I could easily take a 1 or 2 second long impulse and convolve it using Acoustic Mirror with a sound file in real time on my old 600MHz P3 machine. It uses 32bit floating point math, or so is claimed. If your EQ is only 4096 taps long, that is less than 0.1 sec. Should be a breeze. Am I missing something?
Kind regards,
Jim
Thanks for the clarification. I don't think I can hear any degradation or added noise either, but I've not really dug as deep into this as I'd like.
I understand your argument, and do understand what FFT based convolution is. However, your processing power estimates don't match my experience using Sonic Foundry's Acoustic Mirror. It uses FFT based convolution using the overlap and add method, since the impulse responses to be convolved can be quite long. I could easily take a 1 or 2 second long impulse and convolve it using Acoustic Mirror with a sound file in real time on my old 600MHz P3 machine. It uses 32bit floating point math, or so is claimed. If your EQ is only 4096 taps long, that is less than 0.1 sec. Should be a breeze. Am I missing something?
Kind regards,
Jim
Acoustic Mirror
Had a quick look on the net for Acoustic Mirror and found no mention of how it is implemented internally. You said it works real time. What was the latency? If it's small or zero it is definitely not just overlap-add (given that your impulse responses were seconds in length). Simple overlap-add requires a latency in the order of the impulse response length. Lake technologies has a proprietory zero latency fast convolution (protected by patent). I don't know if they are using that algorithm or not.
Beyond that, it may well be possible to do float FFT's faster than I pointed out but not with easily portable code. If it is using floating point math then it is probably using Intels highly optimised DSP library which obviously isn't at all portable. Remember thatI'm aiming to make HarBal as portable as possible. As it stands my 32 bit fixed point code has very little in it that needs customising for each platform. Just a handfull of inline functions with some inline assembly.
Once you get into the business of hand coded and optimised assembler language it is getting really machine specific and not at all portable. There is no significant hand coded optimised assembler in my source base. The compiler takes care of the lot. That makes for much more portable code and that is the way it is going to stay.
I'm just not interested in the "can of worms" that highly hand optimised code entails, especially when it is highly platform specific. As it is, it is pretty efficient and accurate enough for the purpose it was intended for. Spending 70-80% of my time on stuff that may give, at best, a 1-5% improvement in quality just makes not sense.
Regards,
Paavo.
Beyond that, it may well be possible to do float FFT's faster than I pointed out but not with easily portable code. If it is using floating point math then it is probably using Intels highly optimised DSP library which obviously isn't at all portable. Remember thatI'm aiming to make HarBal as portable as possible. As it stands my 32 bit fixed point code has very little in it that needs customising for each platform. Just a handfull of inline functions with some inline assembly.
Once you get into the business of hand coded and optimised assembler language it is getting really machine specific and not at all portable. There is no significant hand coded optimised assembler in my source base. The compiler takes care of the lot. That makes for much more portable code and that is the way it is going to stay.
I'm just not interested in the "can of worms" that highly hand optimised code entails, especially when it is highly platform specific. As it is, it is pretty efficient and accurate enough for the purpose it was intended for. Spending 70-80% of my time on stuff that may give, at best, a 1-5% improvement in quality just makes not sense.
Regards,
Paavo.
-
Terpsichore
Acoustic Mirror convolution
Paavo,
Thanks for looking into this. I don't mean to suggest that you need to change anything. Really meant more for my own understanding.
Acoustic Mirror does not use the Lake zero latency convolution algorithm, because there is a latency proportional to impulse length. I don't think it's as long as the impulse, though. seems to me it is more like several hundred milliseconds for a 2 sec impulse.
As for the effect of your fixed precision FFT process, I 've done some more experiments. So far, I can't hear any degradation on music or pure tones so I'm happy with it as it is.
My intent is not to criticize, I think the program is very powerful and very cool. I just want to be sure it's as good as the best, sonically.
Jim
Thanks for looking into this. I don't mean to suggest that you need to change anything. Really meant more for my own understanding.
Acoustic Mirror does not use the Lake zero latency convolution algorithm, because there is a latency proportional to impulse length. I don't think it's as long as the impulse, though. seems to me it is more like several hundred milliseconds for a 2 sec impulse.
As for the effect of your fixed precision FFT process, I 've done some more experiments. So far, I can't hear any degradation on music or pure tones so I'm happy with it as it is.
My intent is not to criticize, I think the program is very powerful and very cool. I just want to be sure it's as good as the best, sonically.
Jim
Acoustic Mirror convolution
Jim,
No offense taken and thanks for your undertstanding, and I would really like to know if you do find anything sonically troubling so that I can have it fixed ASAP.
From what you've mentioned on the latency issue with Acoustic Mirror, I have a pretty clear nothing of how they've implemented it.
I undestand your concerns and would also like to make it as powerful and sonically pleasing as possible, provided I can do so with a clean code base that is easily maintained. Over optimisation can create real headaches in code maintenance so I'd like to avoid that as much as practically possible.
Regards,
Paavo.
No offense taken and thanks for your undertstanding, and I would really like to know if you do find anything sonically troubling so that I can have it fixed ASAP.
From what you've mentioned on the latency issue with Acoustic Mirror, I have a pretty clear nothing of how they've implemented it.
I undestand your concerns and would also like to make it as powerful and sonically pleasing as possible, provided I can do so with a clean code base that is easily maintained. Over optimisation can create real headaches in code maintenance so I'd like to avoid that as much as practically possible.
Regards,
Paavo.