DIY DSP for Digital Room Correction
 User Name Stay logged in? Password
 Home Forums Rules Articles diyAudio Store Blogs Gallery Wiki Register Donations FAQ Calendar Search Today's Posts Mark Forums Read Search

 Digital Source Digital Players and Recorders: CD , SACD , Tape, Memory Card, etc.

 Please consider donating to help us continue to serve you. Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
blu_line
diyAudio Member

Join Date: Jan 2002
Location: The Netherlands
Quote:
 If I create my own simple "filter" by entering coeffs manually in a text file I can actually get some sort of filtering happening now without tons of distortion / clipping. When I say a simple filter, I mean very simple like using taps of 1 2 3 4 5 repeating every 32 taps or something like that - I'm not using proper filter coeffs yet due to the problems below....
@Ozone
I have done my FIR core in VHDL and i can supply you with the code if you like.
A practical hint: When testing the FIR do a simulation with actual coefficients and start testing by supplying a '1' to the system, followed by zero data. When all goes well the coeffiecients come out again.

@Wingfeather
Quote:
 For 32-bit filter coefficients, I tend to use a 2.30 format, since filter coefficients often require a range between plus- and minus-two.
It is a question of scaling is it ?

best regards

Simon

Wingfeather
diyAudio Member

Join Date: Mar 2003
Location: Mountain View, CA
Quote:
 Originally posted by blu_line Please elaborate !
I don't know exactly what you're asking, but I'll expand a little on what I meant by "2.30 format".

Fractional binary could be described as 1.(n-1), in that there is one bit to the left of the decimal place and n-1 bits to the right. Since the value of this bit that's to the left of the decimal point is -1, this fractional number system is capable of representing numbers between -1 and 1 - (2 ^ -(n-1)). This is generally how it is thought of, although, as I said in my previous post, the existence of a decimal place is really just a nice imaginary detail that simplifies things.

The problem is that, in IIR filters at least, you often want coefficients that are greater than 1 in magnitude. They can be very large at times, depending on the filter you want, and that's a problem. But most of the time I've personally found a range of plus/minus-two to be fine. In order to do this you move the figurative decimal point one place to the right, to give you a 2.(n-2) format. This doesn't really change anything on it's own, since the binary pattern you get from the multiplier is the same. However, the weighting of the bits at the output is now different and it's important that this is remembered when doing subsequent operations.

In order to use the output of a filter based on the 2.30 format (or, to be clear, a filter based on the 1.31 format for the audio data and the 2.30 format for the coefficients) for a DAC, for example, you must remember to shift values left by one place before outputting them, or else you'll be introducing a gain of -6dB and also losing one bit of resolution. This shift means that it's now possible for things to clip at this stage, so it's important to be careful.
__________________
Wingfeather

 23rd January 2008, 06:55 AM #103 abzug Account Disabled   Join Date: Jan 2006 Location: whereisit Uh, why not just use floating point? Much harder to mess up. And don't forget that when you use a FIR, intersample peaks over 0 dB can be generated, and there's no amount of headroom that can guarantee they won't occur for every possible input.
Wingfeather
diyAudio Member

Join Date: Mar 2003
Location: Mountain View, CA
Quote:
 Originally posted by abzug Uh, why not just use floating point? Much harder to mess up.
Implementing floating-point on an FPGA might be a bit of a pain (though there are presumably libraries for this...). Besides, it has its own problems, uses lots more logic, and can't be dithered. Floating point using lots of bits is okay, but the problems of logic usage and general fussyness get worse. I guess it could be worth a try eventually, but I think the OP is having trouble enough with fixed-point so far!

Quote:
 Originally posted by abzug there's no amount of headroom that can guarantee they won't occur for every possible input
Not true - the maximum output that can occur is very easy to calculate for an FIR filter. The maximum instantaneous output you can get is when the audio samples are all full scale, with their signs matching that of their respective coefficients. In other words, it's the sum of the magnitudes of all of the coefficients.
__________________
Wingfeather

abzug
Account Disabled

Join Date: Jan 2006
Location: whereisit
Quote:
 Originally posted by Wingfeather it's the sum of the magnitudes of all of the coefficients.
Oops, you are correct, my mistake.
Sounds like a good reason that every FIR should be normalized.

 26th January 2008, 05:54 PM #106 Wingfeather   diyAudio Member   Join Date: Mar 2003 Location: Mountain View, CA Well, sorta - it would introduce some gain though. But if you want some gain anyway then I guess amplifying the coefficients is as good a way as any. __________________ Wingfeather
 8th June 2008, 01:34 PM #108 OzOnE_2k3   diyAudio Member   Join Date: Jul 2005 Location: Devon Hi, I did some more reading last night and I've started to make sense of some of this. I think the main confusion is that things are dependant on which "realm" they are in. ie. "real" or "binary / hex". The real numbers only exist on say the PC side and the filter coeffs need to be converted to Q15 first so a fixed-point DSP can process them.... I did a simple practical example of multiplying (using the Q15 format)... I took two random (arbitrary) "real" numbers of 0.23 and 0.38, and converted these to Q15 - I scaled them by first multiplying them by 32767 (the Q15 coeff?)... 0.23 x 32767 = 7536 = 1D70 in HEX 0.38 x 32767 = 12451 = 30A3 in HEX These numbers have been rounded when stored as Q15 due to quantization (I think that's the general term). I then took the hex Q15 numbers and multiplied... 1D70 x 30A3 = 597BE50 (Q30 hex?)... During the initial multiply, the "Q15 coefficient" (32767) applied to the original "real" numbers gets multiplied too, so you need to scale this back down again to get the proper Q15 result.... 597BE50 / 7FFF = B2F This now gives us the Q15 result of the multiply. ie. B2F (hex) = 2863 (decimal).... Convert to "real" again: 2863 / 32767 = 0.08737449 etc. What I couldn't get to work is shifting the Q30 result bits left, then taking the top 16 bits as the Q15 result? So, I can see now that the Q15 format is basically a way of representing the real data inside a fixed-point DSP. The input data has to be converted / scaled first, and some logic has to be changed or added to calculate the correct result(s). Ok, so if my input audio data is 16-bit signed (-32768 to 32767), how would I normalize using binary operations to make the samples less than 1 and convert to Q15? Or, do I even need to convert the samples? I hope this can help others too, but please don't take all of this as accurate, as I'm not 100% on anything yet. OzOnE.
 9th June 2008, 06:24 AM #109 mako1138   diyAudio Member   Join Date: Nov 2007 My impression from reading those slides is that you don't need to do anything to go between two's complement int and Q15. It's a matter of reinterpreting where the decimal point goes, and using different rules for multiplication. For example, we can multiply 3 by 4 to get 12. We can also multiply 0.3 and 0.4 to get 0.12, but we have to remember to "add the decimals" or whatever they called it back in grade school. Looking around, people seem to use 32768 as the Q15 multiplier. This makes multiplies and divides clean 15-bit shifts. Going with your example again: 0.23 x 32768 = 7537 = 0x1d71 0.38 x 32768 = 12452 = 0x30a4 0x1d71 x 0x30a4 = 0x5980C64, or 0000 0101 1001 1000 0000 1100 0110 0100 (result in bold) 0000 1011 0011 0000 = 0xB30 = 2864 2864 / 32768 = 0.0874 Sanity check: 0.23 x 0.38 = 0.0874 If we had been working under the int paradigm, we'd have gotten 7537 x 12452 = 93850724 which overflows. But by reinterpreting ints as Q15, we can multiply without worrying about overflow.

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is Off Forum Rules
 Forum Jump User Control Panel Private Messages Subscriptions Who's Online Search Forums Forums Home Site     Site Announcements     Forum Problems Amplifiers     Solid State     Pass Labs     Tubes / Valves     Chip Amps     Class D     Power Supplies     Headphone Systems Source & Line     Analogue Source     Analog Line Level     Digital Source     Digital Line Level     PC Based Loudspeakers     Multi-Way     Full Range     Subwoofers     Planars & Exotics Live Sound     PA Systems     Instruments and Amps Design & Build     Parts     Equipment & Tools     Construction Tips     Software Tools General Interest     Car Audio     diyAudio.com Articles     Music     Everything Else Member Areas     Introductions     The Lounge     Clubs & Events     In Memoriam The Moving Image Commercial Sector     Swap Meet     Group Buys     The diyAudio Store     Vendor Forums         Vendor's Bazaar         Sonic Craft         Apex Jr         Audio Sector         Acoustic Fun         Chipamp         DIY HiFi Supply         Elekit         Elektor         Mains Cables R Us         Parts Connexion         Planet 10 hifi         Quanghao Audio Design         Siliconray Online Electronics Store         Tubelab     Manufacturers         AKSA         Audio Poutine         Musicaltech         Aussie Amplifiers         CSS         exaDevices         Feastrex         GedLee         Head 'n' HiFi - Walter         Heatsink USA         miniDSP         SITO Audio         Twin Audio         Twisted Pear         Wild Burro Audio

 Similar Threads Thread Thread Starter Forum Replies Last Post kipman725 Multi-Way 3 7th August 2009 01:13 PM mr.duck Digital Line Level 1 23rd June 2009 05:49 PM wigginjs Multi-Way 37 24th February 2008 07:10 PM Radian Multi-Way 1 7th February 2007 08:10 PM

 New To Site? Need Help?

All times are GMT. The time now is 09:37 PM.