Wingfeather said:
30 instructions per biquad? Unless SHARCs are way less efficient than Motorola (now Freescale [sounds like a movie drug]) DSPs, you won't be using anything like that for biquads.
In any event, biquads are mostly useful in the bottom end for room correction of floor-to-ceiling and wall-to-wall resonances. Mids and highs are better sorted out by room treatments where possible.
FIRs are also useful for straightening out driver curves, particularly in the mids and especially the highs. I wouldn't discount them for low-mid crossovers, either, since I suspect the ear is more sensitive to phase response in the low mids than anyplace else.
And you've probably discovered that FIRs for a given frequency become four times as expensive when the sampling rate is doubled: a factor of two because you're now computing twice as many FIRs per second, and another factor of two because the FIR is now twice as long. There doesn't seem to be much call for running filters much beyond 64 kHz, anyway, since by then the space between the Nyquist frequency and the ear's passband is adequate. You could run at that rate all day and never hear any difference between that and 192 kHz, while saving 8/9 of your processing power.
You don't need the full double precision multiplier. Consider two 36 bit numbers, A+b and C+d, with A and C as the most significant words, and b and d as the least significant. Multiplying them together yields a product composed of A*C + A*d + C*b + b*d. A*C is not right-shifted at all. while A*d and C*b are right-shifted by 18 bits because one of the multipliers is right-shifted by 18 places. Note that b*d ends up shifted to the right by 36 bits, so for most purposes you can ignore the result and not bother calculating it. That'll save you one multiplier of 4, so you can use a 3S200 instead of a 3S400 for a multiplier-driven design.
<type type type> Crikey. The prices on these things are pretty darned good. On the other hand, soldering all those little pins...
DSP_Geek said:
Now, I've done some work with PIC chips and FPGAs before, but DSPs look like a different beast altogether! While I understand binary theory to some extent, I'm still having trouble with the basic steps to convolution....
(Don't get me wrong though, this is definitely the sort of discussion I was looking for.)
The main issue for me is to roughly calculate how much power is needed, how long the filters need to be, what the sample rate needs to be, and how many channels we can do simultaneously....
Personally, I'm looking at doing full-range DRC using FIR filters generated by Denis Sbragion's DRC package.....
http://www.duffroomcorrection.com
These filters correct for much of the time response as well as the frequency response. I'm currently using it on 2 channels using the PC (can do 8 channels, but cabling and practicality is a pain), but a multichannel standalone DSP unit is the ultimate aim.
Am I getting this roughly right?.... (I've never found a really good diagram of this process, but the attached image is a basic 4-tap FIR filter).....
The "Z -1" sections are where each incoming audio sample is delayed by one sample as it goes "through" each tap and onto the next "Z -1" section. This happens once every clock tick (ie. at the chosen sample rate.)
The FIR filter samples are loaded into C0, C1, C2, C3 etc. (known as the filter "coefficients"). You then have to multiply all of the incoming samples (stored in the "Z" sections) by the FIR filter samples (stored in the C0, C1, C2, C3 sections). The results of all these multiplies are then added together to give the new output audio sample.
As each sample clock "tick" happens, the incoming samples progress through to the next "Z -1" section until they reach the end of the filter. The filter coefficients (C0, C1 etc.) only change when you want to change the filter itself.
(ie. the incoming audio samples are in a queue which is as long as the filter length. Eventually, all incoming samples will have past through every tap until they reach the end and are discarded (or "fall off"!). In the example diagram, this is only 4 taps, but we would need a few thousand taps.)
The reason it can get expensive is because all of the stored taps need to be multiplied by all of the filter samples, and then the totals added together before the next incoming audio sample arrives. (ie. all calculated 48,000 times per second, or whatever sample rate you're using.)
(People with keen eyes may have noticed that I've changed from "bits" to "samples" because I realized that each incoming (and outgoing) sample is actually a discreet sample, and not just one bit! eg. for 16-bit audio, each sample can have a value from 0 to 65535 etc.)
If this does describe most of the basic process, then I'm sure it could be quite easy to achieve using an FPGA instead of a DSP chip. Even fairly long filters could be processed in parallel at high clock speeds. I even have a small FPGA kit (Pluto II) which I could try some code on.
Now I just need to work out how long the filter needs to be (as a minimum) to perform decent enough room correction.....
I've tried altering the filter length on Pristine Space to around 50ms, and there doesn't seem to be much audible difference at all between 50ms and 300ms as far as sound quality and bass response goes. So, a 50ms filter at 48KHz would have 2400 taps. Normally, this would need 115,200,000 MACs to process on your average DSP (with one MAC per clock)....
With an FPGA, it should be possible to process all 2400 taps within only a few clock cycles. With many FPGAs running at 50MHz and above, it should be an excellent solution.
(I know that the filter length relates to the frequencies which can pass through, and the resolution etc. but I haven't looked into the theory of this much yet.)
I must point out that much of this is still guesswork, and I'm by no means an expert. I might be missing something here, but does this look roughly correct so far? Be gentle!
OzOnE.
Attachments
I haven't followed the whole thread so excuse me if the following has been mentioned already:
Go and buy a book on multirate signal-processing. The money you spend on the book is easily made up by the savings on hardware. As an additional advantage you have learnt something new.
Regards
Charles
Hi,
Thanks for the advise. I think I may have to look out for a book on the subject. Usually much better than trying to piece things together from the Web (and we all know the Web is always accurate! - not)
Then again, I've pretty much always learnt things as I go along, and from info on the Web. For example, I know pretty much exactly how DLP projectors work now (down to the way they split each frame into "bitplanes" consisting of the bit weightings from the original frame, then give each bitplane a certain amount of time on screen so the eye sees the correct shades of a certain colour etc.), but that's another subject!
I might actually have had a DSP book in the past, but never up reading them. I'm much more used to learning by practical example, or taking things apart.
OzOnE.
Thanks for the advise. I think I may have to look out for a book on the subject. Usually much better than trying to piece things together from the Web (and we all know the Web is always accurate! - not)
Then again, I've pretty much always learnt things as I go along, and from info on the Web. For example, I know pretty much exactly how DLP projectors work now (down to the way they split each frame into "bitplanes" consisting of the bit weightings from the original frame, then give each bitplane a certain amount of time on screen so the eye sees the correct shades of a certain colour etc.), but that's another subject!
I might actually have had a DSP book in the past, but never up reading them. I'm much more used to learning by practical example, or taking things apart.
OzOnE.
Well indeed. That's how I'm doing it myself right now, although with a normal PC. I do very much like the idea of a standalone DSP box though - a regular PC is big, takes ages to switch on, uses loads of power, and is really just a bit inelegant. Those mini-/nano-/pico-ITX boards look interesting! I wonder what the DSP capability of the C7 processors is, though...
I'm using a LynxTWO so the sound quality is good, but similar results could definitely be achieved for less hardware cost in a dedicated system. Plus, it will be lots of fun to develop! I've just been putting off the big development effort due to lack of time and other things. Plus I have no experience at DSP hardware so it'll be a big learning curve. Definitely want to go this way one day, though.
Oi you, stop picking holes! It was really an off-the-top-of-the head number - and I thought it better to be mega-conservative (same with choosing 192kHz, really). I had a quick think through it and I think a biquad done "properly", with an efficient dither generator like an LCG, will take about 20 instructions - explicitly, that is. I'm not familiar with the SHARC's instruction set so I don't know how much can be saved by doing things in parallel. I'd assume there will be a reasonable saving though, since these things are designed for this job. Obviously, a quick 'n' nasty biquad can be done with five multiplies and a shift. But I'm not considering that option as suitable
Well sure, from that point of view - but isn't it coneivable that people will use high sample-rate inputs to this thing? The idea of downsampling everything just to run it through the DRC filters sounds nasty to me. I only really chose the 192kHz example as a way of being flexible about things - I'm sure compromises can be made later.
Anyway!
Well maybe. But then longer FIR filters have more in the way of pre-echo and all of that stuff. I don't think anybody knows which is more important - if indeed, either of them are - so it's hard to know where to go.
OzOnE_2k3, your description of the FIR filter sounds just about right. Wikipedia has a reasonable diagram of the process, which you might find useful.
OzOnE_2k3 said:
I haven't looked at DRC yet, as the past year found me covered in sawdust and ABS chips (sewer pipe makes great ducting, but cutting it to length is a right pain).
That's pretty well it, except filter coefficients are never called samples - it's too confusing. That term is reserved for audio data.
That's an awfully long filter. I tend to prefer shorter filters for everything, precisely to avoid preringing on crossovers and such nastiness. I explained earlier how longer FIRs can typically be replaced with IIRs, because filters of that length would mostly be used for correcting room and woofer responses, both of which are quite tractable with IIRs.
It is not necessary to perform the filtering on 192kHz audio data as there is no information in the higher frequencies. The reasonable thing to do is to down sample the data to 48 kHz (or a little higher), apply the filtering and up sample it before sending the data to the DACs.
As far as I know, the only reason for having a high sample rate is because the distortion of the DAC can be moved up in frequency and filtered away by a analog low pass filter.
If the digital signal processing is done with lower sample frequency you will save a lot of processing power that can be used for other things..
When using long FIR filters you do not want to do it in the time-domain, you want to do the filtering in the frequency-domain as it is MUCH faster.
FIR filters in the time-domain has a complexity of O(m*n) where (lets say) m is the number of samples and n is the number of filter coefficients.
The FFT algorithm has a complexity of O(n*log2
) where n is the number of filter coefficients. If we have the same number of filter coefficients and filter taps (n=m), the frequency-domain filtering will take O(n*log2) << O(n^2) time.Some people want to use IIR filters instead of FIR which is good if you want short delays (like in a home theater system) or have slow processor but in a hifi-system FIR filters is the way to go. The problems with IIR filters is that they can be hard to design and if they are poorly designed the can be unstable and begin to oscillate which is not good!
Also when using IIR filters you will have to carefully match the poles and zeros in each biquad to make the gain of each biquad be as close to 1 as possible. You will also have to take the quantization errors of a fixed point implementation in consideration to make the filter stable. A FIR filter is always stable.
Perhaps the best feature of a FIR filter is that it can be made phase-linear, which is something IIR filters can not be.
Hi folks
Also I'm interested in FIR crossover. I ordered C6713 DSK last week
I wrote a little prototype for FIR channel cross over and Room correction with very straight FIR coding.
attached contains...
(1)FIRCalc01.cpp
This code reads Frequency config and EQ config,
Calculate Desired frequency responce
Calculate FIR coefficients and kaiser window processing
Calculate simulated Frequency responce
read wav file, process FIR and outputs.
made by VisualStudio 2005 but minimized Windows dependency.
(2)300_3000 BPF folder
Freq.txt "300.0, 3000.0" first number is Low cut freq, second is High cut freq. if Low cut = 0 then it is LPF.
Coeffs.txt: calculated FIR Coeffs.
Kaiser.txt: Kaiser window value.
Fres.csv: simulated response.
Output_spectrum.txt: white noise is processed by (1), and output was analyzed by Audacity, then result is exported.
(3)EQProcess folder
Freq.txt "0.0, 30000.0" so no stop/pass bands.
EQ.txt contains some frequency and desired dB.
Coeffs.txt: (same)
Kaiser.txt: (same)
Fres.csv: (same)
Output_spectrum.txt: (same) original wav level was -12dB adjusted.
This prototype eats simple configuration and generates crazy accurate Filter coeffs, both for crossover and room correction.
I assume C6713 can process total 4095TAP/44100 stereo.
(4095 TAPS for 44100 results 10Hz resolution EQ)
(or 1023x4way crossover is also easy to make)
I can't believe myself because it work out toooo fine.
Could anyone who has knowledge for signal processing, re-inspect this?
Also I'm interested in FIR crossover. I ordered C6713 DSK last week
I wrote a little prototype for FIR channel cross over and Room correction with very straight FIR coding.
attached contains...
(1)FIRCalc01.cpp
This code reads Frequency config and EQ config,
Calculate Desired frequency responce
Calculate FIR coefficients and kaiser window processing
Calculate simulated Frequency responce
read wav file, process FIR and outputs.
made by VisualStudio 2005 but minimized Windows dependency.
(2)300_3000 BPF folder
Freq.txt "300.0, 3000.0" first number is Low cut freq, second is High cut freq. if Low cut = 0 then it is LPF.
Coeffs.txt: calculated FIR Coeffs.
Kaiser.txt: Kaiser window value.
Fres.csv: simulated response.
Output_spectrum.txt: white noise is processed by (1), and output was analyzed by Audacity, then result is exported.
(3)EQProcess folder
Freq.txt "0.0, 30000.0" so no stop/pass bands.
EQ.txt contains some frequency and desired dB.
Coeffs.txt: (same)
Kaiser.txt: (same)
Fres.csv: (same)
Output_spectrum.txt: (same) original wav level was -12dB adjusted.
This prototype eats simple configuration and generates crazy accurate Filter coeffs, both for crossover and room correction.
I assume C6713 can process total 4095TAP/44100 stereo.
(4095 TAPS for 44100 results 10Hz resolution EQ)
(or 1023x4way crossover is also easy to make)
I can't believe myself because it work out toooo fine.
Could anyone who has knowledge for signal processing, re-inspect this?
To the very best of my knowledge, that is untrue. The point of recording things at high sample rates is not to mitigate D/A conversion problems - you can just use an oversampling DAC for that, and most people do - it's to capture high-frequency information. I do not have any 192kHz source material with which I can prove this, however... anyone have any thoughts?
It is much faster, but it's not equal in other areas. An FFT-based convolution requires multiple stages of processing, each with a numerical truncation, and the result is going to be of lower quality than the time-domain equivalent. The truncations cannot be dithered conventionally as they can in the time domain because not much is known about what exactly it means to dither in the frequency domain. And what domain are you really in when you're moving between time and frequency?
If you're able to do an FFT-convolution with lots of precision then this isn't going to be an issue, but with 32-bit floating-point arithmetic you are unlikely to be able to get 24-bit transparency out of it. With 40-bit, then maybe.
That is quite a... shortsighted(?) way to see things. FIR is not intrinsically better than IIR, it is just different. There are times when IIR does a better job (any time you need a minimum-phase response is one example) - the lower latency and computational cost are just very welcome side benefits. They can oscillate if they are badly designed, sure, but with good practice it's easy to ensure they are stable and not have to worry about it. Certainly, if you're using the number of bits that are being talked about here (e.g. 32-bit coefficients) coefficient-quantization is highly unlikely to cause problems with pole movement.
Wingfeather said:
Oi you, stop picking holes! It was really an off-the-top-of-the head number - and I thought it better to be mega-conservative (same with choosing 192kHz, really). I had a quick think through it and I think a biquad done "properly", with an efficient dither generator like an LCG, will take about 20 instructions - explicitly, that is. I'm not familiar with the SHARC's instruction set so I don't know how much can be saved by doing things in parallel. I'd assume there will be a reasonable saving though, since these things are designed for this job. Obviously, a quick 'n' nasty biquad can be done with five multiplies and a shift. But I'm not considering that option as suitable
I'll pick a few more nits. (Le Bureau De La Mission Civilisatrice Francaise would take away my passport if I passed up a chance at harassing a Brit
)In Motorola DSP, I have a filter with double-precision feedback and single-precision feedforward, all you need if the signal fits within a single precision word, which takes 16 clocks (NOT instructions, since some of those take two clocks). You can add dither if you want, but it'll be rather superfluous.
You also don't need to calculate dither for every filter, either. Pseudo-random generators have signals with zero autocorrelation at all points except the generator period. You can merely generate one dither, feed it into a circular buffer (which DSPs support really well), and read from different offsets for the various places where you need a dither signal, with confidence the different dither signals will be random with respect to each other. Some limitations apply, of course: a dither offset of 1 delay would be useless for dithering consecutive low pass IIRs, because the filters preserve enough state that the dither would no longer be pseudo-random. You want to pick offsets where the impulse response is low enough there's no chance of the dither being correlated.
Actually, you lose NOTHING by running your filters at lower frequencies, and especially if you're running FIRs in active systems crossed over by FIRs. Consider a mid-tweeter crossover at 2 kHz. You can bet the response at 6 kHz will be well in the stopband, so you can consider the crossover filter a decimation filter. With that knowledge, you can run a midrange correction FIR at 12 kHz. There will be no aliasing since signals above the Nyquist frequency (6 kHz) will contain no energy at all. Now 12 kHz FIRs will require 1/256 of the computational power of FIRs running at 192 kHz. Subsequent upsampling them will require a fraction of the saved cycles. The upsampling does involved a slight latency of one or two milliseconds, but in the grand scheme of things that's a roundoff error.
Short FIRs are where it's at for crossovers, because they have less latency, consume less DSP, and show less pre-echo artifacts off-axis.
One more point: room correction occurs in the bass, perhaps the low mids. As a result the IIRs for that task could live in the bass/mid section of the crossover, after the decimation I mentioned above, which is helpful since IIRs are more tractable the higher their effective frequencies are with respect to the sampling frequency. Implementing a 50 Hz IIR for 192 kHz sampling rate is a miserable job, but it's a lot simpler to build the same IIR for 12 kHz sampling rate.
Oooh, I like it. Hadn't thought of that one.
That's another nice saving. I hadn't thought it that far through. But obviously, that works nicely. Very elegant
I've never actually implemented one on anything other than a PC, so I'm perfectly happy to concede to you here. So, turns out biquads are super-cheap. Awesome!
I hate to say this... are you sure you don't mean FIR, there? Or do you mean IIR filters using 24-bit coefficients (since you mention the Motorola)? I can see why they might get difficult at 192kHz - but with 32-bit coefficients I think any cutoff above a few Hz or so won't be a problem, even at that samplerate.
That's definitely my stance on the topic.
KOON3876, I had a quick look over your code and short of a full-on debug session, which would take bloody ages, it seems perfectly reasonable. The sanity-check which comes to mind first is to just compare what your code produces against something like the output from MATLAB. That's one thing I do when I write code, at least, just because there's so much scope for little errors to go unnoticed in something like this.
I have implemented XO and roomcorrection with ADSP-21369 ez kit. After 1024 tap Subwoof, 512 tap woofer, and 512 tap tweeter FIR filters (for left and right channels) , there was MIPS left only for 1024 tap room correction filters. Everything is running at 48kHz.
http://kotisivu.dnainternet.net/eskvi/web/Filter2.PNG
Sharc assebly language is pretty easy, and the FIRs were implemented in time domain with Analog SIMD (paraller processing) examples.
Some might say that my filters length is overkill, but at least I don't hear any pre-echoes.
1000 tap FIR filter does not equalize under 100Hz. Below 100Hz I would be also looking IIRs. Behringer Feedback destroyer or
VS8033 Antimode
Anyway, all these are still bit pricey. I am also looking for something better for DIY purposes. I am planning 5.1 system..
This Antimode looks interesing. It is made by small company, that makes MP3 player engines. I guess that Antimode is made from their (16eur) vs1033 chip, which has DSP, 1 ADC and 2 DACs on same chip. They have prototyping board and evaluation kit for the vs1033 chip too, which are reasonable price range (below 200eur).
Unfortunately the vs1033 spec says that SNR of line in is about 60dB. Also the performance at 48kHz bit unclear..
http://kotisivu.dnainternet.net/eskvi/web/Filter2.PNG
Sharc assebly language is pretty easy, and the FIRs were implemented in time domain with Analog SIMD (paraller processing) examples.
Some might say that my filters length is overkill, but at least I don't hear any pre-echoes.
1000 tap FIR filter does not equalize under 100Hz. Below 100Hz I would be also looking IIRs. Behringer Feedback destroyer or
VS8033 Antimode
Anyway, all these are still bit pricey. I am also looking for something better for DIY purposes. I am planning 5.1 system..
This Antimode looks interesing. It is made by small company, that makes MP3 player engines. I guess that Antimode is made from their (16eur) vs1033 chip, which has DSP, 1 ADC and 2 DACs on same chip. They have prototyping board and evaluation kit for the vs1033 chip too, which are reasonable price range (below 200eur).
Unfortunately the vs1033 spec says that SNR of line in is about 60dB. Also the performance at 48kHz bit unclear..
veskelin said:
What is the nature of the room correction? Looking at Putzey's AES presentation, simple approaches even to a subset of the problem like speaker equalization have a lot of problems: http://www.hypex.nl/docs/Bruno Masterclass/slides.htm
It seems to me a quality solution requires the processing power of a personal computer.
Crossover-wise, what about using IIR and then FIR for equalization and phase correction? I got this idea from John Kreskovsky's crossover writings and also because something like this has been done in some DAC oversampling filters.
BTW, I also have the ADSP-21369 and will be using it for oversampling, but later on I might consider adding crossover as well, so this topic is of interest to me.
Wingfeather said:
I compared mine and DSPLinks (freesoft, up to 400 Taps), attached. It looks like almost same impulse responce both has.
Daveis said:
I thought TI library has good conversion from float to I2S 24bit, but it should be considered to use dither if no lib routine.
white noise were generated by WaveGene (Free).
This prototype takes almost 2 minutes to process 1 minutes wav file, so it can not be VST plugin
My room correction filters were done using Denis Sbragions drc. They are doing fine job
My measurements
I have not actually studied detaing theory behind drc. Definetely it is something more sophisticated than "brute force" zero forcing algorithm. My coeffs are done using default "soft" params, which makes somehow good compromise between on-axis and off-axis perf.
The impact of drc was quite amazing in my system. After the project I felt that IIR crosover might have done the job also. I was using 8" Seas Excel woofer, which has nasty resonanses at 5000kHz. Therefore steep filters were justified.
Wingfeather said:
[...] That's another nice saving. I hadn't thought it that far through. But obviously, that works nicely. Very elegant
Thanks. The dayjobs do pay me to think about things like this, so the practice tends to roll over into here. These techniques aren't proprietary [1] so no trade secrets are involved.
[1] Or at least they won't be unless I start a company. Nelson's been a bad influence on me, however, so enjoy.
Anyway, here's another reason why decimating the midrange FIR could be useful. Consider that speaker resonances will max out at a Q of about 10 or 20 whether the driver is a tweeter or a midrange, but the midrange's peak will be lower in the spectrum (no kidding). Also consider the rough rule of thumb that FIR frequency resolution is about equal to the sample rate divided by number of taps. A 100 Hz error in correcting a 10 kHz tweeter peak is a 1% error, insignificant for a Q=10 peak, whereas a 100 Hz error to correct 1 kHz is a 10% error, enough to fail when correct a Q=10 peak, so you want a FIR with 10 Hz resolution. As a result, one needs longer FIRs to get the equivalent correction for mids as compared with tweeters, which would increase cycle count if they're computed at full rate.
Not quite. Coefficients get worse with lowered frequency or increased Q. Room correction involves the worst of both worlds, where one might encounter a high-Q resonance at very low frequencies, so the deleterious effect on coefficient values is compounded, to the point where I've seen some values not far from 10^-5 at 64 kHz sample rate. 32 bits gets you a dynamic range of 2*10^-9, so that leaves about 86 dB after ONE filter of room correction. Not horrible, but not quite optimal either. For a 2nd order IIR running at low frequencies, halving the sample rate decreases coefficient sensitivity by a factor of (roughly) four, so running the same filters at 16 kHz improves the coefficients by 16, or about 24 dB. That brings us to 110 dB, or something more usable, so even with 32 bit math you want to either run at half-double precision or decimated sample rate when doing serious room correction.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.