Re: [Bluez-devel] sbc and fixed-point progress

Victor Shcherbatyuk
2005-07-28T18:41:51Z

Brad,

I'll send it in on weekend, still want to play a bit with precisions and
possibly do some optimizations.... I think large precision parts under some
conditions can be ignored, cause they will be cut anyway when converting
back to 16 bit integer at the end (or they have very small impact on the
final result). But, of course, it should be done only after some
consideration....

I think 32 bit is the way to go, esp. for arm, and afterwards, lame mp3 is
working fine with 32-bit....

Regards,
Victor.

----- Original Message -----
From: "Brad Midgley" <bmidgley@xmission.com>
To: <bluez-devel@lists.sourceforge.net>
Sent: Thursday, July 28, 2005 16:59
Subject: Re: [Bluez-devel] sbc and fixed-point progress

> Victor,
>
> Great! Can you send me the output of "cvs diff -u" or the resulting sbc.c?
>
> Even if it's noisy, we will just make it optional using the compile-time
> option and improve it over time. Right now we have no way at all to encode
> on arm, so even a noisy encoder would be going in the right direction.
>
> I started working on the decoder but got stuck when I found that the
> state->W and state->X variables sometimes needed large precision and
> sometimes had large integer parts (ie in a naive fixed-point
> implementation, they would need more than 32 bits). I was contemplating
> keeping a large precision in the fixed point type but using a separate
> integer for those variables' integer part.
>
> Brad
>
> Victor Shcherbatyuk wrote:
>> Hello Brad,
>>
>> FYI,
>>
>> Yesterday I converted encoder to fixed point (I did it a dirty way, so
>> probably it doesn't have much of the value). I've converted each of the
>> tables with different precision in such a way that the operations
>> involving the tables (mults and adds) will not overflow 32 bit, and
>> where necessary I pre-shift intermediate results to prevent overlowing.
>> Currently the output is a slightly noisy, but the purpose was to
>> estimate required performance. The result is, in the current
>> implementation, using fixed point it is just about to be enough to run
>> on 400Mhz arm combined with mp3 decoder (mp3 piped though mad mp3
>> decoder to sbc encoder to a2play). This means either something is wrong
>> :) or SBC codec should be heavily optimized (3 - 5 times ?) to make it
>> reasonable (memcopies is the first thing to optimize probably)...
>>
>> Regards,
>> Victor.
>>
>>
>> -----Original Message-----
>> From: bluez-devel-admin@lists.sourceforge.net
>> [mailto:bluez-devel-admin@lists.sourceforge.net] On Behalf Of Brad
>> Midgley
>> Sent: Monday, July 04, 2005 6:03 AM
>> To: BlueZ Mailing List
>> Subject: [Bluez-devel] sbc and fixed-point progress
>>
>> Guys,
>>
>> just FYI...
>>
>> I found a decent fixed point multiply that preshifts the values before
>> multiplying them. It keeps things in 32 bits. Most of the roundoff error
>> is taken care of in two additional terms. I think the result is
>> reasonable.
>> (http://www.accu.org/acornsig/public/caugers/volume2/issue6/fixedpoint.h
>> tml)
>>
>> If you compile with fixed-point on, libsbc will run both the fixed and
>> floating point calculations and flag errors when they differ too much.
>> It seems to be working well and has helped me catch a couple of
>> fixed-point calculation problems.
>>
>> I have the decoder almost finished but I probably need to split some
>> terms into integer and fixed-point components. Loading up
>> frame->sb_sample for example can have a big integer part but we want to
>> use most of the 32 bit fixed-point type for the fractional part.
>>
>> Brad
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>> informative Webcasts and more! Get everything you need to get up to
>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>> _______________________________________________
>> Bluez-devel mailing list
>> Bluez-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>>
>>
>> This e-mail message contains information which is confidential and may be
>> privileged. It is intended for use by the addressee only. If you are not
>> the intended addressee, we request that you notify the sender immediately
>> and delete or destroy this e-mail message and any attachment(s), without
>> copying, saving, forwarding, disclosing or using its contents in any
>> other way. TomTom N.V., TomTom International BV or any other company
>> belonging to the TomTom group of companies will not be liable for damage
>> relating to the communication by e-mail of data, documents or any other
>> information.
>>
>>
>> -------------------------------------------------------
>> SF.Net email is Sponsored by the Better Software Conference & EXPO
>> September
>> 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>> Agile & Plan-Driven Development * Managing Projects & Teams * Testing &
>> QA
>> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>> _______________________________________________
>> Bluez-devel mailing list
>> Bluez-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September
> 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices