> 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" <[email protected]>
To: <[email protected]>
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" <[email protected]>
> To: <[email protected]>
> 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: [email protected]
>>> [mailto:[email protected]] 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
>>> [email protected]
>>> 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
>>> [email protected]
>>> 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
>> [email protected]
>> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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"
> <[email protected]>
> To: <[email protected]>
> 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" <[email protected]>
>> To: <[email protected]>
>> 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: [email protected]
>>>> [mailto:[email protected]] 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
>>>> [email protected]
>>>> 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
>>>> [email protected]
>>>> 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
>>> [email protected]
>>> 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
>> [email protected]
>> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel