Hello Anu,  

Supplementing what has already been written, I recommend that since this is
your first attempt at Float to Fixed conversion, you may want to plan the
activity at block level. This implies that you divide your CODEC into
various computational blocks and convert them one-at-a-time.

You may start at the CODEC's input-output interface and determine the
precision loss for your choosen Q-format. Accordingly the Q-Format may be
modified.  For a 16 bit processor architecture Q15 is a good starting point
while for a 32 bit processor architecture Q31 may be tried.

Once you have stablised your input-output interface, you may want to perform
similar exercise for various other computational blocks. 

A classical problem in the Float To Fixed conversion is the "propagation of
error". A good conversion seeks to converge these errors. Some of the
techniques for minimising the error divergence are based on the CODEC
algorithm and also on the individual requirements of the various
computational blocks. Most Speech CODECs will behave well in Fixed Point if
you implement some form of Rounding mechanism at critical points.  "Round
to
nearest even" is the most popular and mathematically the most stable
rounding scheme. 

Finally, you may find that the Float To Fixed conversion is an iterative
process, where you may be able to implement more optimal solutions once the
edifice is ready. In that respect it is as much of an art as it is science.
	Best Regards,

Umang Garg
	NeoMagic Corporation delivers semiconductor chips and software that provide
mobile solutions that enable new multimedia features for handheld devices.
These solutions offer low power consumption, small form-factor and high
performance processing. The Company demonstrated one of the first solutions
used for H.264 video decoding in a mobile digital TV phone, and is
developing and delivering solutions for audio/video processing of the
dominant mobile digital TV standards, including ISDB-T, DMB, and DVB-H. For
its complete system solution, NeoMagic delivers a suite of middleware and
sample applications for imaging, video and audio functionality, and provides
multiple operating system ports with customized drivers for the MiMagic
product family. NeoMagic has a patent portfolio of over 25 patents that
cover NeoMagic's proprietary array processing technology, embedded DRAM and
other technology. Information on the company may be found on the World Wide
Web at www.neomagic.com.
	> -----Original Message-----
> From: speechcoding@spee... 
> [mailto:speechcoding@spee...] On Behalf Of Phil Frisbie, Jr.
> Sent: Wednesday, February 15, 2006 12:31 AM
> To: a_p_21@a_p_...
> Cc: speechcoding@spee...
> Subject: Re: [speechcoding] Regarding float to fixed point conversion
> 
> anu prabhu wrote:
> 
> >  
> > 
> > Hello !!
> > 
> > I am working on float to fixed point conversion of a Speech Codec.
> 
> Good luck to you! The very first codec I converted took MANY 
> times longer than I anticipated, and then it took many hours 
> to make the code stable under extreme conditions.
> 
> > The input to the speech codec (floating one) is 16 bit PCM.
> > 
> > Fixed point representation has its own limitations of hadling the 
> > dynamic range (which is not there in floating point ). So 
> How should I 
> > treat the input samples while converting the floating codec 
> to fixed 
> > point one ?
> 
> It depends... I know that is not what you want to hear, but 
> where you start at depends on your code. For example, the 
> types of filters and the way the auto correlation is written 
> will determine the max integer range needed.
> 
> > Because if I take input as 16 bit integer ie . 16.0 format 
> for 16 bit 
> > wordlength and 16.16 format
> > 
> > for 32 bit wordlength , then I feel that down the line I will get 
> > stuck for format decision . (functions like autocorr ...).
> > 
> > Or should I consider the input in 1.15 format for fixed 
> point codec .
> 
> If you are targeting 32 bit CPUs or DSPs, then using 32 bits 
> will make it easier to convert and might even be faster. 
> Converting to 16 bits is MUCH harder due to scaling and then 
> rescaling for each function to prevent overflow while keeping 
> as much precision as possible.
> 
> > Means , even the input is 16 bit PCM for floating codec should we 
> > treat it in 1.15 format while converting the float to fixed 
> point codec ?
> 
> For a real example to look at for a reference, you can 
> download my fixed point conversion of OpenLPC from my site 
> below. I ended up using 12.20 format.
> 
> 
> -- 
> Phil Frisbie, Jr.
> Hawk Software
> http://www.hawksoft.com
>
	

anu prabhu wrote:

>  
> 
> Hello !!
> 
> I am working on float to fixed point conversion of a Speech Codec.

Good luck to you! The very first codec I converted took MANY times longer than I

anticipated, and then it took many hours to make the code stable under extreme 
conditions.

> The input to the speech codec (floating one) is 16
bit PCM.
> 
> Fixed point representation has its own limitations of hadling the 
> dynamic range (which
> is not there in floating point ). So How should I treat the input 
> samples while
> converting the floating codec to fixed point one ?

It depends... I know that is not what you want to hear, but where you start at 
depends on your code. For example, the types of filters and the way the auto 
correlation is written will determine the max integer range needed.

> Because if I take input as 16 bit integer ie .
16.0 format for 16 bit 
> wordlength and 16.16 format
> 
> for 32 bit wordlength , then I feel that down the line I will get stuck 
> for format decision . (functions like autocorr ...).
> 
> Or should I consider the input in 1.15 format for fixed point codec .

If you are targeting 32 bit CPUs or DSPs, then using 32 bits will make it easier

to convert and might even be faster. Converting to 16 bits is MUCH harder due to

scaling and then rescaling for each function to prevent overflow while keeping 
as much precision as possible.

> Means , even the input is 16 bit PCM for floating
codec should we treat 
> it in 1.15 format while converting the float to fixed point codec ?

For a real example to look at for a reference, you can download my fixed point 
conversion of OpenLPC from my site below. I ended up using 12.20 format.
	-- 
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com
	

Hi,
Consideration of format for input sample is nothing
but a perception. If u are considering it as 16.0
means input is not normalized and if u are considering
1.16 means ur considering input as normalized input.
So best choise is to use 1.15 so that there will not
be problem for selecting format for other variables.
But u have to make sure that float code is running
properly with normalized input signal.

Snehal

--- anu prabhu <a_p_21@a_p_...> wrote:
	---------------------------------
	Hello !!

I am working on float to fixed point conversion of a
Speech Codec.

The input to the speech codec (floating one) is 16 bit
PCM.

Fixed point representation has its own limitations of
hadling the dynamic range (which

is not there in floating point ). So How should I
treat the input samples while 

converting the floating codec to fixed point one ?

Because if I take input as 16 bit integer ie . 16.0
format for 16 bit wordlength and 16.16 format 

for 32 bit wordlength , then I feel that down the line
I will get stuck for format decision . (functions like
autocorr ...). 

Or should I consider the input in 1.15 format for
fixed point codec .

Means , even the input is 16 bit PCM for floating
codec should we treat it in 1.15 format while
converting the float to fixed point codec ?

Regards,

Anu
	

Hello !!

I am working on float to fixed point conversion of a Speech Codec.

The input to the speech codec (floating one) is 16 bit PCM.

Fixed point representation has its own limitations of hadling the dynamic range (which

is not there in floating point ). So How should I treat the input samples while

converting the floating codec to fixed point one ?

Because if I take input as 16 bit integer ie . 16.0 format for 16 bit wordlength and 16.16 format

for 32 bit wordlength , then I feel that down the line I will get stuck for format decision . (functions like autocorr ...).

Or should I consider the input in 1.15 format for fixed point codec .

Means , even the input is 16 bit PCM for floating codec should we treat it in 1.15 format while converting the float to fixed point codec ?

Regards,

Anu