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

Brad Midgley
2005-07-28T21:09:03Z

Victor,

So maybe for state->W and state->X I could use a different fixed point
with 16 bits representing the integer. I tried doing everything that way
(only 15 bits remain for the fractional part) but the error compounded
very quickly.

Brad

Victor Shcherbatyuk wrote:
>> possibly do some optimizations.... I think large precision parts under
>> some conditions can be ignored, cause they will be cut anyway when
>> converting
>
>
> by ignored I meant "partially ignored" of course, meaning some precision
> can be lost cause you will lose it anyway converting to 16 bit samples
>
> Regards,
> Victor
>
> ----- Original Message ----- From: "Victor Shcherbatyuk"
> <victor@win.tue.nl>
> To: <bluez-devel@lists.sourceforge.net>
> Sent: Thursday, July 28, 2005 20:41
> Subject: Re: [Bluez-devel] sbc and fixed-point progress
>
>
>> 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
>> 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