DIY DSP for Digital Room Correction - Page 12 - diyAudio
 DIY DSP for Digital Room Correction
 User Name Stay logged in? Password
 Home Forums Rules Articles diyAudio Store Gallery Wiki Blogs 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
diyAudio Member

Join Date: Nov 2007
Quote:
 Originally posted by OzOnE_2k3 It does look like using 32768 is better as it rounds things closer to the real result. The question is, is taking the top bits of the result (apart from the first bit) the same as dividing by 32768 or 32767 ?
The rounding off closer is probably just a fluke. What matters is that 32768 is a more convenient number for binary systems, as 2^15 = 32768. And yes, dividing by 32768 is equivalent to right-shifting by 15 bits, which is really easy on a processor or FPGA. Dividing by 32767 would be really nasty, so it's not done that way.

I'm not too well read in DSP so I can't answer your other questions. For learning, I'd suggest Octave, which is the open-source equivalent of Matlab. You should be able to run WAV files through a filter treatment and play them back without too much trouble.

diyAudio Member

Join Date: Mar 2003
Location: Mountain View, CA
Quote:
 Originally posted by OzOnE_2k3 These numbers have been rounded when stored as Q15 due to quantization (I think that's the general term).
It's only a little thing, but rounding and quantisation/truncation aren't quite the same. Rounding is where you round to nearest (e.g. 0.7 -> 1.0), and truncation is where you discard the fractional part (e.g. 0.7 -> 0.0). In terms of total error effects like distortion, the two behave the same. Truncation however ends up with a small negative DC offset. Rounding is what you want (and can be done by adding 0.5 prior to truncating).

Quote:
 Originally posted by mako1138 My impression from reading those slides is that you don't need to do anything to go between two's complement int and Q15
That's correct. The whole thing is conceptual, and all two's complement gives you is a fraction of whatever range you want to pretend you're using.

Quote:
 Originally posted by OzOnE_2k3 I can now simply take the top bits directly as my result in the FPGA design (ignoring extended sign bit). This will mean simply routing the 16 result bits directly instead of doing a logic divide (probably gets routed the same way anyway if the divide is a power of two though.)
The first part is right - simply taking the top bits is the way to do it. Be careful when comparing it with a divide, though; the result isn't always the same. For example, 1/2 will often come out as a 1 (depending on architecture - writing in C, for example, on the x86), when a right shift will clearly give you zero.

I think the thing to remember is that it's all conceptual. When multiplying two B-bit numbers in two's-complement format, you're going to end up with a result which is 2B bits long. All architectures calculate this double-length result internally, and the bit-pattern will be the same regardless of whether the inputs are integer or have some decimal point in them somewhere. Whether you get an integer or a fractional value overall just depends on whether you take the bottom-half or the top-half, respectively, of this long result as your output.
__________________
Wingfeather

 17th June 2008, 01:31 AM #113 diyAudio Member   Join Date: Aug 2003 Location: Santa Cruz, California Also recall that q15 represents numbers between -1.0 and 0.999..., so that multiplier results must also represent correct numbers in that format. For example, consider 1/2 in q15 = 0x4000. Multiply by 1/2, you get 0x10000000, and taking the top 16 bits as your q15 representation means the 0x1000 converts to 1/8 instead of 1/4! What happened? Well, it turns out multiplying a 1.15 number by another 1.15 number generates a 2.30 number, which means the result is shifted to the right by 1 with respect to the proper result for a 1.31 number (which you would truncate to 1.15). So the proper thing to do after the multiplier is to shift the result left by 1 before truncation. Try it for yourself.
 17th June 2008, 07:36 PM #114 diyAudio Member   Join Date: Jul 2005 Location: Devon Hi, DSP_Geek, I understand the need for the shift / taking the 16 bits directly (ignoring the MSB). I'm still a bit hazy at times because I get confused by Windoze calculator, but if I'm programming things in Verilog I know what I'm "asking" the software to do to the bits directly. (if that makes sense! ) My main hurdle was understanding the concept of how Q15 numbers work and what Q format really is.... Many people / web sites just say something like: "The binary point is effectively moved during calculation", whereas I like to think of it as "Magnifying the original (real) value to bring it towards the binary point during calculation". In reality, what you're doing is magnifying the original (real) values beforehand, then reducing them again after the result. This makes best use of the 16 bit resolution (well, 15 bits + sign) and also "allows" the maths work correctly using the usual integer binary multipliers etc. (The only extra logic you really need to add for Q15 multiplies is for taking the top 16 bits of the Q30 result.) So, as long as you take the top 16 bits and ignore the MSB of the multiplied result, it should all work. ie. the full 32-bit result of 0x4000 (0.5) multiplied by itself is.... 0001 0000 0000 0000 0000 0000 0000 0000 Take the top bits (ignoring MSB), or shift to the left by 1 bit first.... = 001 0000 0000 0000 0 = 0x2000 (hex result) = 0.25 (real number) Again, this is somewhat confused by the fact that taking the top bits is not actually producing your "real-world" (original) value. The reason for taking the top bits is only to convert the Q30 result back to Q15 format again. You have to do this because when the multiply occurs with two Q15 values, the Q15 "scaling factor" (32768) also gets multiplied at the same time. I hope this is mostly correct. Again, this is only my understanding of it so far, and I'm posting this from a definite learners point of view (I'm NO expert!) I've actually got a nice DSP board on the way to me now (TMS320C6711 DSK). I'll try to get some long filters running on that first, then hopefully I can come back to the FPGA stuff with a better understanding. The FPGA design is actually producing results now though (with a very short FIR). OzOnE. P.S. I now have a nice Mauro RevC stereo kit built with a 300VA toroid and Twisted Pear PCBs !!! For anyone wondering about power output from these little LM3886 chips - it easily beats my Denon AVC-A11SR for sheer dynamics and output (before clipping). The Denon is rated at 125 Watts RMS into 8 ohms (20hz-20KHz), so the RevC amp must be doing some sort of voodoo, or just shows that it's much better designed?
 17th June 2008, 08:25 PM #115 diyAudio Member   Join Date: Jul 2005 Location: Devon (I tried to change the above post, but the evil 30 minute rule kicked in.).... Corrections - "Scaling the original (real) value to best fit your 15 fixed bits." + "and also allows you to "keep" the same multiplier logic as you were using for integers." New - OK, so some Q format "prerequisites" are: 1. Convert all your original coeffs to fractional values (confine to between -1 and 1 to help prevent overflow of final results)... 2. Convert these fractions to Q15 format by multiplying by 32768 (will loose a small amount of precision when fit into 15 bits) 3. When two Q15 values are multiplied, take the top 16 bits of the 32-bit result (ignore extended sign / MSB). You don't necessarily have to "see" the real coeff values at all during the processing inside the DSP, you just keep them in Q15 right the way through. If you need to see or check the real values again, just divide the Q15 value by 32768. (for an example; you would normally only see the real coeff values when you initially generate your filter taps on the PC.) I now also get the point about the audio samples - because they are (usually) already confined to a 16-bit signed number (15-bits + sign), they can generally be thought of as already "being in" Q15 format. Because of this you can process them with Q15 methods (as long as it doesn't introduce things like large DC offsets or clipping at the output etc.) OzOnE.

 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 OffTrackbacks are Off Pingbacks are Off Refbacks are Off Forum Rules

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

 New To Site? Need Help?

All times are GMT. The time now is 02:30 AM.