AMR codec implementations

Hi, I am looking at running the AMR 3GPP codec on an ARM9TDMI platform.
This not strictly a DSP, but I've looked around and I haven't seen much
about AMR except the ETSI reference codec so I thought I could ask
here.

My question is - has anybody seen a fixed-point 32-bit implementation
of the AMR reference source anywhere on the net ? It does not have to
be optimized (or bit-exact for that matter), I just wanted to look at
something else than the reference source, preferably without all the
C-code indirections (through the basicops2.c functions).

I know you can buy DSP and ARM optimized versions from several vendors.
Regards,

Bjorn

"BW" <bjorn@sparta.lu.se> writes:

> Hi, I am looking at running the AMR 3GPP codec on an ARM9TDMI platform.
> This not strictly a DSP, but I've looked around and I haven't seen much
> about AMR except the ETSI reference codec so I thought I could ask
> here.
> 
> My question is - has anybody seen a fixed-point 32-bit implementation
> of the AMR reference source anywhere on the net ? It does not have to
> be optimized (or bit-exact for that matter), I just wanted to look at
> something else than the reference source, preferably without all the
> C-code indirections (through the basicops2.c functions).
> 
> I know you can buy DSP and ARM optimized versions from several vendors.
> Regards,
> 
> Bjorn

Hi Bjorn,

Just flying from the cuff, you might try checking some of the free, public-source
players (winamp, etc.). They *may* now have an AMR codec builtin. 
-- 
Randy Yates
Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
randy.yates@sonyericsson.com, 919-472-1124

Hi, Bjorn,
I have porting AMR to ARM926EJ-S.

During this process, i found the reference fixed-point C code is designed
for 16-bit DSP (eg, Ti C54/C55).
Because ARM family are 32-bit cup, it need some extra operations to
implement 16-bit operation.

In order to keep bit-accuracy, I offen shift 16 bit operand to high
halfword of registers before add/sub/mul, etc and then shift the result
back. 
At the same time, i try my best to combine the following operations to
16-bit operations, eg. saturation.

The worst case time consuption is about 50MIPS for ARM926EJ-s. For 920T,
is should be about 65MIPS.

Jason

jasonshi wrote:
> In order to keep bit-accuracy, I offen shift 16 bit operand to high
> halfword of registers before add/sub/mul, etc and then shift the
result
> back.
> At the same time, i try my best to combine the following operations
to
> 16-bit operations, eg. saturation.
>
> The worst case time consuption is about 50MIPS for ARM926EJ-s. For
920T,
> is should be about 65MIPS.

Hi,

do you know if the saturation arithmetics have to be there ? I mean, I
can understand there is a need for it in the bit-accurate reference
implementation, but if enough headroom is given in a "real world"
implementation, maybe it can be removed ? It would simplify operations
much I guess.

50 MIPS sounds like a lot.. you can encode AAC at those frequencies in
only 25 MIPS and that algorithm is quite complex. Do you feel like you
could make more shortcuts in your implementation to speed it up ?

Bjorn

yes. the dynamic range for 32-bit word is wide enough to omit satuaration
in most cases. 
if you don't care about bit-accuracy, you can use WORD32 to replace "int"
in reference code. but, you must take care the dynamic range of the
interim and results. 

At the other hand, in order to keep the original function interface, you
need to convert the returned parameters from WORD32 to WORD16.
Another choice is change all word16 variables and arrays into word32.
Both of these modification, you can save some MIPS.
The former is better in practice.

I'm not familiar with AAC, but i think AMR is more complex than MPEG-1
layII. Maybe 50 MIPS is a acceptable result.
I'm going to speed it up next month. 

Jason

>yes. the dynamic range for 32-bit word is wide enough to omit satuaration
>in most cases. 
>if you don't care about bit-accuracy, you can use WORD32 to replace
"int"
>in reference code. but, you must take care the dynamic range of the
>interim and results. 
>
>At the other hand, in order to keep the original function interface, you
>need to convert the returned parameters from WORD32 to WORD16.
>Another choice is change all word16 variables and arrays into word32.
>Both of these modification, you can save some MIPS.
>The former is better in practice.
>
>I'm not familiar with AAC, but i think AMR is more complex than MPEG-1
>layII. Maybe 50 MIPS is a acceptable result.
>I'm going to speed it up next month. 
>
>Jason
>
>
>
>
Hi, 

Is there a requirement for a bit exact implementation for AMRWB+ decoder.
ie. any thing related to licensing. Can you provide some licensing
information for the decoder

Hari ...