[Bluez-devel] sbc and fixed-point progress

[Bluez-devel] sbc and fixed-point progress

[Brad Midgley]

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.html)

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

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

[Marcel Holtmann]

Hi Brad,

> 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.html)
> 
> 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.

go ahead and keep on with the good work.

However someone might be looking at the SBC algorithm itself. I've been
told that there are a lot of optimizations possible.

Regards

Marcel




-------------------------------------------------------
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

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

[Victor Shcherbatyuk]

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=20
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=3D7477&alloc_id=3D16492&op=3Dclic=
k
_______________________________________________
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 immediatel=
y and delete or destroy this e-mail message and any attachment(s), withou=
t copying, saving, forwarding, disclosing or using its contents in any ot=
her way. TomTom N.V., TomTom International BV or any other company belong=
ing to the TomTom group of companies will not be liable for damage relati=
ng to the communication by e-mail of data, documents or any other informa=
tion.


-------------------------------------------------------
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

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

[Brad Midgley]

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

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

[Victor Shcherbatyuk]

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

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

[Victor Shcherbatyuk]

> 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

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

[Brad Midgley]

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
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

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

[Victor Shcherbatyuk]

Brad,

I've looked at the code once more. Probably you asware of this,  but
using rmagnitude(...)  gives almost no information about required
precision :( . Like for the table value 0.923879532511287 we need 51-bit
to represent it without precision loss, cause during conversion it is
multiplied by 2 ^ nr_prec_bits and then the fractional part is being
thrown away, if we do not want to lose precision the fractional part
should be 0, so 2 ^ nr_prec_bits sholud be equal 10 ^ 15, so
nr_prec_bits =3D 15 log2 10 =3D 49+ ... Plus 1 bit for an integer part + =
1
bit for a sign... -> 51bit

So even assigning 32 bits for a fractional part for a table drops 17
bits... :( .=20

I guess the noise I have after encoding I guess is coming from here.

Regards,
     Victor.

P.S. I'll send in fixed point code for the encoder a bit later, didn't
have much time to clean it up ....

-----Original Message-----
From: bluez-devel-admin@lists.sourceforge.net
[mailto:bluez-devel-admin@lists.sourceforge.net] On Behalf Of Brad
Midgley
Sent: Thursday, July 28, 2005 23:09 PM
To: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] sbc and fixed-point progress

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=20
>> under some conditions can be ignored, cause they will be cut anyway=20
>> when converting
>=20
>=20
> by ignored I meant "partially ignored" of course, meaning some=20
> precision can be lost cause you will lose it anyway converting to 16=20
> bit samples
>=20
> Regards,
> Victor
>=20
> ----- Original Message ----- From: "Victor Shcherbatyuk"=20
> <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
>=20
>=20
>> Brad,
>>
>> I'll send it in on weekend, still want to play a bit with precisions=20
>> and possibly do some optimizations.... I think large precision parts=20
>> under some conditions can be ignored, cause they will be cut anyway=20
>> when converting back to 16 bit integer at the end (or they have very=20
>> small impact on the final result). But, of course, it should be done=20
>> 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"=20
>> <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=20
>>> sbc.c?
>>>
>>> Even if it's noisy, we will just make it optional using the=20
>>> compile-time option and improve it over time. Right now we have no=20
>>> way at all to encode on arm, so even a noisy encoder would be going=20
>>> 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=20
>>> implementation, they would need more than 32 bits). I was=20
>>> contemplating keeping a large precision in the fixed point type but=20
>>> 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=20
>>>> operations involving the tables (mults and adds) will not overflow=20
>>>> 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=20
>>>> estimate required performance. The result is, in the current=20
>>>> implementation, using fixed point it is just about to be enough to=20
>>>> run on 400Mhz arm combined with mp3 decoder (mp3 piped though mad=20
>>>> mp3 decoder to sbc encoder to a2play). This means either something=20
>>>> 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=20
>>>> 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=20
>>>> before multiplying them. It keeps things in 32 bits. Most of the=20
>>>> roundoff error is taken care of in two additional terms. I think=20
>>>> the result is reasonable.
>>>> (http://www.accu.org/acornsig/public/caugers/volume2/issue6/fixedpo
>>>> int.h
>>>>
>>>> tml)
>>>>
>>>> If you compile with fixed-point on, libsbc will run both the fixed=20
>>>> 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=20
>>>> fixed-point calculation problems.
>>>>
>>>> I have the decoder almost finished but I probably need to split=20
>>>> some terms into integer and fixed-point components. Loading up
>>>> frame->sb_sample for example can have a big integer part but we=20
>>>> frame->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=20
>>>> Strategies from IBM. Find simple to follow Roadmaps,=20
>>>> straightforward articles, informative Webcasts and more! Get=20
>>>> everything you need to get up to speed, fast.=20
>>>> http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
>>>> _______________________________________________
>>>> 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=20
>>>> 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=20
>>>> sender immediately and delete or destroy this e-mail message and=20
>>>> any attachment(s), without copying, saving, forwarding, disclosing=20
>>>> or using its contents in any other way. TomTom N.V., TomTom=20
>>>> International BV or any other company belonging to the TomTom group

>>>> of companies will not be liable for damage relating to the=20
>>>> communication by e-mail of data, documents or any other
information.
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> SF.Net email is Sponsored by the Better Software Conference & EXPO=20
>>>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle=20
>>>> Practices Agile & Plan-Driven Development * Managing Projects &=20
>>>> Teams * Testing & QA Security * Process Improvement & Measurement *

>>>> http://www.sqe.com/bsce5sf=20
>>>> _______________________________________________
>>>> 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=20
>>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle=20
>>> Practices Agile & Plan-Driven Development * Managing Projects &=20
>>> Teams * Testing & QA Security * Process Improvement & Measurement *=20
>>> http://www.sqe.com/bsce5sf=20
>>> _______________________________________________
>>> 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=20
>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle=20
>> Practices Agile & Plan-Driven Development * Managing Projects & Teams

>> * Testing & QA Security * Process Improvement & Measurement *=20
>> http://www.sqe.com/bsce5sf=20
>> _______________________________________________
>> Bluez-devel mailing list
>> Bluez-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO=20
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle=20
> Practices Agile & Plan-Driven Development * Managing Projects & Teams=20
> * Testing & QA Security * Process Improvement & Measurement *=20
> http://www.sqe.com/bsce5sf=20
> _______________________________________________
> 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


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 immediatel=
y and delete or destroy this e-mail message and any attachment(s), withou=
t copying, saving, forwarding, disclosing or using its contents in any ot=
her way. TomTom N.V., TomTom International BV or any other company belong=
ing to the TomTom group of companies will not be liable for damage relati=
ng to the communication by e-mail of data, documents or any other informa=
tion.


-------------------------------------------------------
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

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

[Brad Midgley]

Victor

> I've looked at the code once more. Probably you asware of this,  but
> using rmagnitude(...)  gives almost no information about required
> precision :(

it's intended to capture the min and max exponent of the various 
floating point values a variable has at runtime, but, yes, it won't help 
with finding the number of bits required to represent something accurately.

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

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

[Victor Shcherbatyuk]

[-- Attachment #1: Type: text/plain, Size: 6274 bytes --]

Hello Brad,

In the attachment is the patch to support fixed point encoding for 8-subband 
sbc codec. To compie ARM specific version USE_FIXED_ARM should be defined 
(currently in sbc/sbc.c should be in configuration?). It is possible I broke 
your fixed point tables cause I've changed gen_fixed.c, but it should be 
easy fixable.

Floating point implementation is optimized too, runs 30% faster on my 
AthlonXP. General fixed point (long long) runs slower than floating on my 
PC, which is strange... I do not have HW to test arm specific version real 
time, hope no suprises there, but I could have missed something when 
integrating it into sbc code (it decodes well, but how fast, I will try only 
monday evening).

Using a2play needs to tweak 87 magic number, otherwise it drops samples?

Regards,
     Victor.

P.S. There are a lot of changes, I hope I didn't miss any... Please take a 
look, and let me know if something is wrong with it...

----- 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 

[-- Attachment #2: sbc-fixed.patch --]
[-- Type: application/octet-stream, Size: 41154 bytes --]

? sbc/play
? sbc/test.pcm
? sbc/test.sbc
? sbc/test1.sbc
Index: sbc/gen_fixed.c
===================================================================
RCS file: /cvsroot/bluetooth-alsa/btsco/sbc/gen_fixed.c,v
retrieving revision 1.2
diff -u -r1.2 gen_fixed.c
--- sbc/gen_fixed.c	22 Jun 2005 18:08:45 -0000	1.2
+++ sbc/gen_fixed.c	21 Aug 2005 18:26:31 -0000
@@ -1,5 +1,6 @@
 #define USE_FIXED
 
+#include <math.h>
 #include "sbc.h"
 #include "sbc_tables.h"
 
@@ -8,13 +9,15 @@
 	void *ref;
 	int i;
 	int j;
+	int bits;
 } tables[] = {
-	{"sbc_proto_4_40_f", (void *)sbc_proto_4_40, 40, 1},
-	{"sbc_proto_8_80_f", (void *)sbc_proto_8_80, 80, 1},
-	{"synmatrix4_f", (void *)synmatrix4, 8, 4},
-	{"synmatrix8_f", (void *)synmatrix8, 16, 8},
-	{"anamatrix4_f", (void *)anamatrix4, 4, 8},
-	{"anamatrix8_f", (void *)anamatrix8, 8, 16},
+	{"sbc_proto_4_40_f", (void *)sbc_proto_4_40, 40, 1, 28},
+	{"sbc_proto_8_80_f", (void *)sbc_proto_8_80, 80, 1, 28},
+	{"synmatrix4_f", (void *)synmatrix4, 8, 4, 28},
+	{"synmatrix8_f", (void *)synmatrix8, 16, 8, 28},
+	{"anamatrix4_f", (void *)anamatrix4, 4, 8, 28},
+	{"_sbc_proto_8_f", (void *)_sbc_proto_8, 40, 1, 33},
+	{"_anamatrix8_f", (void *)_anamatrix8, 8, 1, 30},
 	{0, 0, 0, 0}
 };
 
@@ -23,15 +26,33 @@
 	float *array;
 	for(entry = 0; tables[entry].name; entry++) {
 		if(tables[entry].j == 1) {
-			printf("static const sbc_fixed_t %s[%d] = {\n",
-			       tables[entry].name, tables[entry].i);
+			if (tables[entry].ref == (void *)_sbc_proto_8 || tables[entry].ref == (void *)_anamatrix8) {
+				if (tables[entry].ref == (void *)_sbc_proto_8)
+					printf("#define FIXED64_STAGE1 %d\n", 24);
+				else
+					printf("#define FIXED64_STAGE2 %d\n", 7);
+				printf("static const int32_t %s[%d] = {\n",
+				       tables[entry].name, tables[entry].i);
+			}
+			else
+				printf("static const sbc_fixed_t %s[%d] = {\n",
+				       tables[entry].name, tables[entry].i);
 			array = (float *)tables[entry].ref;
 			for(i = 0; i < tables[entry].i; i++) {
 				if(i>0) {
 					printf(", ");
 					if(i%8 == 0) printf("\n");
 				}
-				printf("0x%08x", dtofixed(array[i]));
+				double res = array[i]*pow(2, tables[entry].bits);
+				if (res > 0 )
+					res += 0.5;
+				else
+					res += -0.5;
+				if (fabs(res) > (double)(0xFFFFFFFF / 2.0)) {
+					printf("OVERFLOW (%f)!\n", res);
+					exit(1);
+				}
+				printf("0x%08x", (int32_t)res);
 			}
 			printf("\n};\n\n");
 		} else {
@@ -47,7 +68,16 @@
 						printf(", ");
 						if(j%8 == 0) printf("\n");
 					}
-					printf("0x%08x", dtofixed(array[idx++]));
+					double res = array[idx++]*pow(2, tables[entry].bits);
+					if (res > 0 )
+						res += 0.5;
+					else
+						res += -0.5;
+					if (fabs(res) > (double)(0xFFFFFFFF / 2.0)) {
+						printf("OVERFLOW (%f)!\n", res);
+						exit(1);
+					}
+					printf("0x%08x", (int32_t)res);
 				}
 				printf(" }");
 			}
Index: sbc/sbc.c
===================================================================
RCS file: /cvsroot/bluetooth-alsa/btsco/sbc/sbc.c,v
retrieving revision 1.47
diff -u -r1.47 sbc.c
--- sbc/sbc.c	26 Jul 2005 20:30:52 -0000	1.47
+++ sbc/sbc.c	21 Aug 2005 18:26:32 -0000
@@ -36,6 +36,8 @@
 
 */
 
+//#define USE_FIXED_ARM
+
 #ifdef HAVE_CONFIG_H
 #include <config.h>
 #endif
@@ -68,7 +70,6 @@
 	}
 	return 0;
 }
-
 #endif
 
 struct magnitude {
@@ -155,7 +156,7 @@
 /* This structure contains an unpacked SBC frame. 
    Yes, there is probably quite some unused space herein */
 struct sbc_frame {
-	double sampling_frequency;	/* in kHz */
+	u_int16_t sampling_frequency;	/* in kHz */
 	u_int8_t blocks;
 	enum {
 		MONO		= SBC_CM_MONO,
@@ -178,7 +179,7 @@
 	sbc_fixed_t pcm_sample_f[2][16*8];
 #endif
 	double sb_sample[16][2][8];		/* modified subband samples */
-	double pcm_sample[2][16*8];		/* original pcm audio samples */
+	int16_t pcm_sample[2][16*8];		/* original pcm audio samples */
 };
 
 struct sbc_decoder_state {
@@ -196,8 +197,9 @@
 
 struct sbc_encoder_state {
 	int subbands;
-	float S[2][8];				/* Subband samples */
-	float X[2][80], Y[2][16], Z[2][80];	/* Vectors */
+	double S[2][8];				/* Subband samples */
+	double Y[2][16], Z[2][80];		/* Vectors */
+	int32_t X[2][80];
 };
 
 /*
@@ -497,16 +499,16 @@
 	sf = (data[1] >> 6) & 0x03;
 	switch (sf) {
 	case SBC_FS_16:
-		frame->sampling_frequency = 16;
+		frame->sampling_frequency = 16000;
 		break;
 	case SBC_FS_32:
-		frame->sampling_frequency = 32;
+		frame->sampling_frequency = 32000;
 		break;
 	case SBC_FS_44:
-		frame->sampling_frequency = 44.1;
+		frame->sampling_frequency = 44100;
 		break;
 	case SBC_FS_48:
-		frame->sampling_frequency = 48;
+		frame->sampling_frequency = 48000;
 		break;
 	}
 
@@ -794,7 +796,7 @@
 
 	/* Output 4 reconstructed Audio Samples */
 	for (i = 0; i < 4; i++) {
-		frame->pcm_sample[ch][blk * 4 + i] = state->X[ch][i];
+		frame->pcm_sample[ch][blk * 4 + i] = (int16_t)state->X[ch][i];
 #ifdef USE_FIXED
 		frame->pcm_sample_f[ch][blk * 4 + i] = state->X_f[ch][i];
 		assertf(0, frame->pcm_sample[ch][blk * 4 + i], frame->pcm_sample_f[ch][blk * 4 + i], "output samples");
@@ -891,7 +893,7 @@
 
 	/* Ouput 8 reconstructed Audio Samples */
 	for (i = 0; i < 8; i++) {
-		frame->pcm_sample[ch][blk * 8 + i] = state->X[ch][i];
+		frame->pcm_sample[ch][blk * 8 + i] = (int16_t)state->X[ch][i];
 #ifdef USE_FIXED
 		frame->pcm_sample_f[ch][blk * 8 + i] = state->X_f[ch][i];
 		assertf(0, frame->pcm_sample[ch][blk * 8 + i], frame->pcm_sample_f[ch][blk * 8 + i], "output samples");
@@ -973,39 +975,316 @@
 	for (i = 0; i < 4; i++)
 		frame->sb_sample[blk][ch][i] = state->S[ch][i];
 }
+#ifdef USE_FIXED
+static inline void _sbc_analyze_eight(int32_t in[80], int32_t out[8])
+{
+	int32_t a0_hi,a1_hi,a2_hi,a3_hi,a4_hi,a5_hi,a6_hi,a7_hi,a8_hi,a9_hi,a10_hi,a11_hi,a12_hi,a13_hi,a14_hi,a15_hi,a16_hi,a17_hi,a18_hi,a19_hi,a20_hi, a21_hi;
+	int32_t a0_lo,a1_lo,a2_lo,a3_lo,a4_lo,a5_lo,a6_lo,a7_lo,a8_lo,a9_lo,a10_lo,a11_lo,a12_lo,a13_lo,a14_lo,a15_lo,a16_lo,a17_lo,a18_lo,a19_lo,a20_lo, a21_lo;
+	int32_t in1, in2, t1, t2, t3, t4, t5, t6, t7, t8;
+	int32_t t1_hi, t1_lo, t2_hi, t2_lo, t3_hi, t3_lo, t4_hi, t4_lo;
+	int32_t t5_hi, t5_lo, t6_hi, t6_lo, t7_hi, t7_lo, t8_hi, t8_lo;
+	int32_t out0_hi, out1_hi, out2_hi, out3_hi, out4_hi, out5_hi, out6_hi, out7_hi;
+	int32_t out0_lo, out1_lo, out2_lo, out3_lo, out4_lo, out5_lo, out6_lo, out7_lo;
+
+	t1_hi = t1_lo = t2_hi = t2_lo = t3_hi = t3_lo = t4_hi = t4_lo = 0;
+	t5_hi = t5_lo = t6_hi = t6_lo = t7_hi = t7_lo = t8_hi = t8_lo = 0;
+	out0_hi = out1_hi = out2_hi = out3_hi = out4_hi = out5_hi = out6_hi = out7_hi = 0;
+	out0_lo = out1_lo = out2_lo = out3_lo = out4_lo = out5_lo = out6_lo = out7_lo = 0;
+
+	in1 = in[16] - in[64]; in2 = in[32] - in[48];
+	MULA64(t1_hi, t1_lo, _sbc_proto_8_f[0], in1);
+	MULA64(t1_hi, t1_lo, _sbc_proto_8_f[1], in2);
+	MULA64(t1_hi, t1_lo, _sbc_proto_8_f[2], in[4]);
+	MULA64(t1_hi, t1_lo, _sbc_proto_8_f[3], in[20]);
+	MULA64(t1_hi, t1_lo, _sbc_proto_8_f[4], in[36]);
+	MULA64(t1_hi, t1_lo, _sbc_proto_8_f[5], in[52]);
+	t1 = SCALE64(t1_hi, t1_lo, FIXED64_STAGE1);
+
+	MULA64(t2_hi, t2_lo, _sbc_proto_8_f[6], in[2]);
+	MULA64(t2_hi, t2_lo, _sbc_proto_8_f[7], in[18]);
+	MULA64(t2_hi, t2_lo, _sbc_proto_8_f[8], in[34]);
+	MULA64(t2_hi, t2_lo, _sbc_proto_8_f[9], in[50]);
+	MULA64(t2_hi, t2_lo, _sbc_proto_8_f[10], in[66]);
+	t2 = SCALE64(t2_hi, t2_lo, FIXED64_STAGE1);
+
+	MULA64(t3_hi, t3_lo, _sbc_proto_8_f[11], in[1]);
+	MULA64(t3_hi, t3_lo, _sbc_proto_8_f[12], in[17]);
+	MULA64(t3_hi, t3_lo, _sbc_proto_8_f[13], in[33]);
+	MULA64(t3_hi, t3_lo, _sbc_proto_8_f[14], in[49]);
+	MULA64(t3_hi, t3_lo, _sbc_proto_8_f[15], in[65]);
+	MULA64(t3_hi, t3_lo, _sbc_proto_8_f[16], in[3]);
+	MULA64(t3_hi, t3_lo, _sbc_proto_8_f[17], in[19]);
+	MULA64(t3_hi, t3_lo, _sbc_proto_8_f[18], in[35]);
+	MULA64(t3_hi, t3_lo, _sbc_proto_8_f[19], in[51]);
+	MULA64(t3_hi, t3_lo, _sbc_proto_8_f[20], in[67]);
+	t3 = SCALE64(t3_hi, t3_lo, FIXED64_STAGE1);
+
+	MULA64(t4_hi, t4_lo, _sbc_proto_8_f[21], in[5]);
+	MULA64(t4_hi, t4_lo, _sbc_proto_8_f[22], in[21]);
+	MULA64(t4_hi, t4_lo, _sbc_proto_8_f[23], in[37]);
+	MULA64(t4_hi, t4_lo, _sbc_proto_8_f[24], in[53]);
+	MULA64(t4_hi, t4_lo, _sbc_proto_8_f[25], in[69]);
+	MULA64(t4_hi, t4_lo, -_sbc_proto_8_f[15], in[15]);
+	MULA64(t4_hi, t4_lo, -_sbc_proto_8_f[14], in[31]);
+	MULA64(t4_hi, t4_lo, -_sbc_proto_8_f[13], in[47]);
+	MULA64(t4_hi, t4_lo, -_sbc_proto_8_f[12], in[63]);
+	MULA64(t4_hi, t4_lo, -_sbc_proto_8_f[11], in[79]);
+	t4 = SCALE64(t4_hi, t4_lo, FIXED64_STAGE1);
+
+	MULA64(t5_hi, t5_lo, _sbc_proto_8_f[26], in[6]);
+	MULA64(t5_hi, t5_lo, _sbc_proto_8_f[27], in[22]);
+	MULA64(t5_hi, t5_lo, _sbc_proto_8_f[28], in[38]);
+	MULA64(t5_hi, t5_lo, _sbc_proto_8_f[29], in[54]);
+	MULA64(t5_hi, t5_lo, _sbc_proto_8_f[30], in[70]);
+	MULA64(t5_hi, t5_lo, -_sbc_proto_8_f[10], in[14]);
+	MULA64(t5_hi, t5_lo, -_sbc_proto_8_f[9], in[30]);
+	MULA64(t5_hi, t5_lo, -_sbc_proto_8_f[8], in[46]);
+	MULA64(t5_hi, t5_lo, -_sbc_proto_8_f[7], in[62]);
+	MULA64(t5_hi, t5_lo, -_sbc_proto_8_f[6], in[78]);
+	t5 = SCALE64(t5_hi, t5_lo, FIXED64_STAGE1);
+
+	MULA64(t6_hi, t6_lo, _sbc_proto_8_f[31], in[7]);
+	MULA64(t6_hi, t6_lo, _sbc_proto_8_f[32], in[23]);
+	MULA64(t6_hi, t6_lo, _sbc_proto_8_f[33], in[39]);
+	MULA64(t6_hi, t6_lo, _sbc_proto_8_f[34], in[55]);
+	MULA64(t6_hi, t6_lo, _sbc_proto_8_f[35], in[71]);
+	MULA64(t6_hi, t6_lo, -_sbc_proto_8_f[20], in[13]);
+	MULA64(t6_hi, t6_lo, -_sbc_proto_8_f[19], in[29]);
+	MULA64(t6_hi, t6_lo, -_sbc_proto_8_f[18], in[45]);
+	MULA64(t6_hi, t6_lo, -_sbc_proto_8_f[17], in[61]);
+	MULA64(t6_hi, t6_lo, -_sbc_proto_8_f[16], in[77]);
+	t6 = SCALE64(t6_hi, t6_lo, FIXED64_STAGE1);
+
+	in1 = in[8] + in[72];
+	MULA64(t7_hi, t7_lo, _sbc_proto_8_f[36], in1);
+	MULA64(t7_hi, t7_lo, _sbc_proto_8_f[37], in[24]);
+	MULA64(t7_hi, t7_lo, _sbc_proto_8_f[38], in[40]);
+	MULA64(t7_hi, t7_lo, _sbc_proto_8_f[37], in[56]);
+	MULA64(t7_hi, t7_lo, -_sbc_proto_8_f[39], in[12]);
+	MULA64(t7_hi, t7_lo, -_sbc_proto_8_f[5], in[28]);
+	MULA64(t7_hi, t7_lo, -_sbc_proto_8_f[4], in[44]);
+	MULA64(t7_hi, t7_lo, -_sbc_proto_8_f[3], in[60]);
+	MULA64(t7_hi, t7_lo, -_sbc_proto_8_f[2], in[76]);
+	t7 = SCALE64(t7_hi, t7_lo, FIXED64_STAGE1);
+
+	MULA64(t8_hi, t8_lo, _sbc_proto_8_f[35], in[9]);
+	MULA64(t8_hi, t8_lo, _sbc_proto_8_f[34], in[25]);
+	MULA64(t8_hi, t8_lo, _sbc_proto_8_f[33], in[41]);
+	MULA64(t8_hi, t8_lo, _sbc_proto_8_f[32], in[57]);
+	MULA64(t8_hi, t8_lo, _sbc_proto_8_f[31], in[73]);
+	MULA64(t8_hi, t8_lo, -_sbc_proto_8_f[25], in[11]);
+	MULA64(t8_hi, t8_lo, -_sbc_proto_8_f[24], in[27]);
+	MULA64(t8_hi, t8_lo, -_sbc_proto_8_f[23], in[43]);
+	MULA64(t8_hi, t8_lo, -_sbc_proto_8_f[22], in[59]);
+	MULA64(t8_hi, t8_lo, -_sbc_proto_8_f[21], in[75]);
+	t8 = SCALE64(t8_hi, t8_lo, FIXED64_STAGE1);
+
+	MUL64(a0_hi, a0_lo, _anamatrix8_f[0], t1);
+	MUL64(a7_hi, a7_lo, _anamatrix8_f[1], t1);
+	ADD64(out0_hi, out0_lo, a0_hi, a0_lo);
+	ADD64(out7_hi, out7_lo, a0_hi, a0_lo);
+	SUB64(out3_hi, out3_lo, a0_hi, a0_lo);
+	SUB64(out4_hi, out4_lo, a0_hi, a0_lo);
+	ADD64(out1_hi, out1_lo, a7_hi, a7_lo);
+	ADD64(out6_hi, out6_lo, a7_hi, a7_lo);
+	SUB64(out5_hi, out5_lo, a7_hi, a7_lo);
+	SUB64(out2_hi, out2_lo, a7_hi, a7_lo);
+
+	MUL64(a21_hi, a21_lo, _anamatrix8_f[7], t2);
+	ADD64(out0_hi, out0_lo, a21_hi, a21_lo);
+	ADD64(out1_hi, out1_lo, a21_hi, a21_lo);
+	ADD64(out2_hi, out2_lo, a21_hi, a21_lo);
+	ADD64(out3_hi, out3_lo, a21_hi, a21_lo);
+	ADD64(out4_hi, out4_lo, a21_hi, a21_lo);
+	ADD64(out5_hi, out5_lo, a21_hi, a21_lo);
+	ADD64(out6_hi, out6_lo, a21_hi, a21_lo);
+	ADD64(out7_hi, out7_lo, a21_hi, a21_lo);
+
+	MUL64(a1_hi, a1_lo, _anamatrix8_f[2], t3);
+	MUL64(a8_hi, a8_lo, _anamatrix8_f[3], t3);
+	MUL64(a13_hi, a13_lo, _anamatrix8_f[4], t3);
+	MUL64(a17_hi, a17_lo, _anamatrix8_f[5], t3);
+	ADD64(out0_hi, out0_lo, a1_hi, a1_lo);
+	SUB64(out7_hi, out7_lo, a1_hi, a1_lo);
+	ADD64(out1_hi, out1_lo, a8_hi, a8_lo);
+	SUB64(out6_hi, out6_lo, a8_hi, a8_lo);
+	ADD64(out2_hi, out2_lo, a13_hi, a13_lo);
+	SUB64(out5_hi, out5_lo, a13_hi, a13_lo);
+	ADD64(out3_hi, out3_lo, a17_hi, a17_lo);
+	SUB64(out4_hi, out4_lo, a17_hi, a17_lo);
+
+	MUL64(a2_hi, a2_lo, _anamatrix8_f[3], t4);
+	MUL64(a9_hi, a9_lo, _anamatrix8_f[5], t4);
+	MUL64(a14_hi, a14_lo, _anamatrix8_f[2], t4);
+	MUL64(a18_hi, a18_lo, _anamatrix8_f[4], t4);
+	ADD64(out0_hi, out0_lo, a2_hi, a2_lo);
+	SUB64(out7_hi, out7_lo, a2_hi, a2_lo);
+	SUB64(out1_hi, out1_lo, a9_hi, a9_lo);
+	ADD64(out6_hi, out6_lo, a9_hi, a9_lo);
+	SUB64(out2_hi, out2_lo, a14_hi, a14_lo);
+	ADD64(out5_hi, out5_lo, a14_hi, a14_lo);
+	SUB64(out3_hi, out3_lo, a18_hi, a18_lo);
+	ADD64(out4_hi, out4_lo, a18_hi, a18_lo);
+
+	MUL64(a3_hi, a3_lo, _anamatrix8_f[6], t5);
+	ADD64(out0_hi, out0_lo, a3_hi, a3_lo);
+	ADD64(out7_hi, out7_lo, a3_hi, a3_lo);
+	ADD64(out3_hi, out3_lo, a3_hi, a3_lo);
+	ADD64(out4_hi, out4_lo, a3_hi, a3_lo);
+	SUB64(out1_hi, out1_lo, a3_hi, a3_lo);
+	SUB64(out2_hi, out2_lo, a3_hi, a3_lo);
+	SUB64(out5_hi, out5_lo, a3_hi, a3_lo);
+	SUB64(out6_hi, out6_lo, a3_hi, a3_lo);
+
+	MUL64(a4_hi, a4_lo, _anamatrix8_f[4], t6);
+	MUL64(a10_hi, a10_lo, _anamatrix8_f[2], t6);
+	MUL64(a15_hi, a15_lo, _anamatrix8_f[5], t6);
+	MUL64(a19_hi, a19_lo, _anamatrix8_f[3], t6);
+	ADD64(out0_hi, out0_lo, a4_hi, a4_lo);
+	SUB64(out7_hi, out7_lo, a4_hi, a4_lo);
+	SUB64(out1_hi, out1_lo, a10_hi, a10_lo);
+	ADD64(out6_hi, out6_lo, a10_hi, a10_lo);
+	ADD64(out2_hi, out2_lo, a15_hi, a15_lo);
+	SUB64(out5_hi, out5_lo, a15_hi, a15_lo);
+	ADD64(out3_hi, out3_lo, a19_hi, a19_lo);
+	SUB64(out4_hi, out4_lo, a19_hi, a19_lo);
+
+	MUL64(a5_hi, a5_lo, _anamatrix8_f[1], t7);
+	MUL64(a11_hi, a11_lo, _anamatrix8_f[0], t7);
+	ADD64(out0_hi, out0_lo, a5_hi, a5_lo);
+	ADD64(out7_hi, out7_lo, a5_hi, a5_lo);
+	SUB64(out3_hi, out3_lo, a5_hi, a5_lo);
+	SUB64(out4_hi, out4_lo, a5_hi, a5_lo);
+	SUB64(out1_hi, out1_lo, a11_hi, a11_lo);
+	SUB64(out6_hi, out6_lo, a11_hi, a11_lo);
+	ADD64(out2_hi, out2_lo, a11_hi, a11_lo);
+	ADD64(out5_hi, out5_lo, a11_hi, a11_lo);
+
+	MUL64(a6_hi, a6_lo, _anamatrix8_f[5], t8);
+	MUL64(a12_hi, a12_lo, _anamatrix8_f[4], t8);
+	MUL64(a16_hi, a16_lo, _anamatrix8_f[3], t8);
+	MUL64(a20_hi, a20_lo, _anamatrix8_f[2], t8);
+	ADD64(out0_hi, out0_lo, a6_hi, a6_lo);
+	SUB64(out7_hi, out7_lo, a6_hi, a6_lo);
+	SUB64(out1_hi, out1_lo, a12_hi, a12_lo);
+	ADD64(out6_hi, out6_lo, a12_hi, a12_lo);
+	ADD64(out2_hi, out2_lo, a16_hi, a16_lo);
+	SUB64(out5_hi, out5_lo, a16_hi, a16_lo);
+	SUB64(out3_hi, out3_lo, a20_hi, a20_lo);
+	ADD64(out4_hi, out4_lo, a20_hi, a20_lo);
+
+	// restore original scale
+	out[0] = out0_hi >> FIXED64_STAGE2;
+	out[1] = out1_hi >> FIXED64_STAGE2;
+	out[2] = out2_hi >> FIXED64_STAGE2;
+	out[3] = out3_hi >> FIXED64_STAGE2;
+	out[4] = out4_hi >> FIXED64_STAGE2;
+	out[5] = out5_hi >> FIXED64_STAGE2;
+	out[6] = out6_hi >> FIXED64_STAGE2;
+	out[7] = out7_hi >> FIXED64_STAGE2;
+
+}
+#else
+static inline void _sbc_analyze_eight(int32_t in[80], double out[8])
+{
+	double t1,t2,t3,t4,t5,t6,t7,t8, in1, in2;
+	double a0,a1,a2,a3,a4,a5,a6,a7,a8,a9,a10,a11,a12,a13,a14,a15,a16,a17,a18,a19,a20;
+
+	out[0] = out[1] = out[2] = out[3] = out[4] = out[5] = out[6] = out[7] = 0;
+
+	in1 = in[16] - in[64]; in2 = in[32] - in[48];
+	t1 = _sbc_proto_8[0]*in1 + _sbc_proto_8[1]*in2 +\
+	     _sbc_proto_8[2]*in[4] + _sbc_proto_8[3]*in[20] +  _sbc_proto_8[4]*in[36] +\
+	     _sbc_proto_8[5]*in[52];
+
+	t2 = _sbc_proto_8[6]*in[2] + _sbc_proto_8[7]*in[18] + \
+	     _sbc_proto_8[8]*in[34] + _sbc_proto_8[9]*in[50] + _sbc_proto_8[10]*in[66];
+
+	t3 = _sbc_proto_8[11]*in[1] + _sbc_proto_8[12]*in[17] + \
+	     _sbc_proto_8[13]*in[33] + _sbc_proto_8[14]*in[49] + _sbc_proto_8[15]*in[65] +\
+	     _sbc_proto_8[16]*in[3] + _sbc_proto_8[17]*in[19] + _sbc_proto_8[18]*in[35] +\
+	     _sbc_proto_8[19]*in[51] + _sbc_proto_8[20]*in[67];
+
+	t4 = _sbc_proto_8[21]*in[5] + _sbc_proto_8[22]*in[21] + \
+	     _sbc_proto_8[23]*in[37] + _sbc_proto_8[24]*in[53] + _sbc_proto_8[25]*in[69] -\
+	     _sbc_proto_8[15]*in[15] - _sbc_proto_8[14]*in[31] - _sbc_proto_8[13]*in[47] -\
+	     _sbc_proto_8[12]*in[63] - _sbc_proto_8[11]*in[79];
+
+	t5 = _sbc_proto_8[26]*in[6] + _sbc_proto_8[27]*in[22] + \
+	     _sbc_proto_8[28]*in[38] + _sbc_proto_8[29]*in[54] + _sbc_proto_8[30]*in[70] -\
+	     _sbc_proto_8[10]*in[14] - _sbc_proto_8[9]*in[30] - _sbc_proto_8[8]*in[46] -\
+	     _sbc_proto_8[7]*in[62] - _sbc_proto_8[6]*in[78];
+
+	t6 = _sbc_proto_8[31]*in[7] + _sbc_proto_8[32]*in[23] + \
+	     _sbc_proto_8[33]*in[39] + _sbc_proto_8[34]*in[55] + _sbc_proto_8[35]*in[71] -\
+	     _sbc_proto_8[20]*in[13] - _sbc_proto_8[19]*in[29] - _sbc_proto_8[18]*in[45] -\
+	     _sbc_proto_8[17]*in[61] - _sbc_proto_8[16]*in[77];
+
+	in1 = in[8] + in[72];
+	t7 = _sbc_proto_8[36]*in1 + _sbc_proto_8[37]*in[24] + \
+	     _sbc_proto_8[38]*in[40] + _sbc_proto_8[37]*in[56] - _sbc_proto_8[39]*in[12] -\
+	     _sbc_proto_8[5]*in[28] - _sbc_proto_8[4]*in[44] - _sbc_proto_8[3]*in[60] -\
+	     _sbc_proto_8[2]*in[76];
+
+	t8 = _sbc_proto_8[35]*in[9] + _sbc_proto_8[34]*in[25] + \
+	     _sbc_proto_8[33]*in[41] + _sbc_proto_8[32]*in[57] + _sbc_proto_8[31]*in[73] -\
+	     _sbc_proto_8[25]*in[11] - _sbc_proto_8[24]*in[27] -_sbc_proto_8[23]*in[43] -\
+	     _sbc_proto_8[22]*in[59] - _sbc_proto_8[21]*in[75];
+
+	a0 = _anamatrix8[0]*t1;
+	a7 = _anamatrix8[1]*t1;
+	out[0] += a0;	out[1] += a7;	out[2] -= a7;	out[3] -= a0;	out[4] -= a0;	out[5] -= a7;	out[6] += a7;	out[7] += a0;
+
+	out[0] += t2;	out[1] += t2;	out[2] += t2;	out[3] += t2;	out[4] += t2;	out[5] += t2;	out[6] += t2;	out[7] += t2;
+
+	a1 = _anamatrix8[2]*t3;
+	a8 = _anamatrix8[3]*t3;
+	a13 = _anamatrix8[4]*t3;
+	a17 = _anamatrix8[5]*t3;
+	out[0] += a1;	out[1] += a8;	out[2] += a13;	out[3] += a17;	out[4] -= a17;	out[5] -= a13;	out[6] -= a8;	out[7] -= a1;
+
+	a2 = _anamatrix8[3]*t4;
+	a9 = _anamatrix8[5]*t4;
+	a14 = _anamatrix8[2]*t4;
+	a18 = _anamatrix8[4]*t4;
+	out[0] += a2;	out[1] -= a9;	out[2] -= a14;	out[3] -= a18;	out[4] += a18;	out[5] += a14;	out[6] += a9;	out[7] -= a2;
+
+	a4 = _anamatrix8[4]*t6;
+	a10 = _anamatrix8[2]*t6;
+	a15 = _anamatrix8[5]*t6;
+	a19 = _anamatrix8[3]*t6;
+	out[0] += a4;	out[1] -= a10;	out[2] += a15;	out[3] += a19;	out[4] -= a19;	out[5] -= a15;	out[6] += a10;	out[7] -= a4;
+
+	a3 = _anamatrix8[6]*t5;
+	out[0] += a3;	out[1] -= a3;	out[2] -= a3;	out[3] += a3;	out[4] += a3;	out[5] -= a3;	out[6] -= a3;	out[7] += a3;
+
+	a5 = _anamatrix8[1]*t7;
+	a11 = _anamatrix8[0]*t7;
+	out[0] += a5;	out[1] -= a11;	out[2] += a11;	out[3] -= a5;	out[4] -= a5;	out[5] += a11;	out[6] -= a11;	out[7] += a5;
+
+	a6 = _anamatrix8[5]*t8;
+	a12 = _anamatrix8[4]*t8;
+	a16 = _anamatrix8[3]*t8;
+	a20 = _anamatrix8[2]*t8;
+	out[0] += a6;	out[1] -= a12;	out[2] += a16;	out[3] -= a20;	out[4] += a20;	out[5] -= a16;	out[6] += a12;	out[7] -= a6;
+}
+#endif
 
 static inline void sbc_analyze_eight(struct sbc_encoder_state *state,
-				struct sbc_frame *frame, int ch, int blk)
+				     struct sbc_frame *frame, int ch, int blk)
 {
-	int i, k;
+	int i;
 
 	/* Input 8 Audio Samples */
 	for (i = 79; i >= 8; i--)
 		state->X[ch][i] = state->X[ch][i - 8];
 	for (i = 7; i >= 0; i--)
 		state->X[ch][i] = frame->pcm_sample[ch][blk * 8 + (7 - i)];
-
-	/* Windowing by 80 coefficients */
-	for (i = 0; i < 80; i++)
-		state->Z[ch][i] = sbc_proto_8_80[i] * state->X[ch][i];
-
-	/* Partial calculation */
-	for (i = 0; i < 16; i++) {
-		state->Y[ch][i] = 0;
-		for (k = 0; k < 5; k++)
-			state->Y[ch][i] += state->Z[ch][i + k * 16];
-	}
-
-	/* Calculate 8 subband samples by Matrixing */
-	for (i = 0; i < 8; i++) {
-		state->S[ch][i] = 0;
-		for (k = 0; k < 16; k++)
-			state->S[ch][i] += anamatrix8[i][k] * state->Y[ch][k];
-	}
-
-	/* Output 8 Subband Samples */
-	for (i = 0; i < 8; i++)
-		frame->sb_sample[blk][ch][i] = state->S[ch][i];
+#ifdef USE_FIXED
+	_sbc_analyze_eight(state->X[ch], frame->sb_sample_f[blk][ch]);
+#else
+	_sbc_analyze_eight(state->X[ch], frame->sb_sample[blk][ch]);
+#endif
 }
 
 static int sbc_analyze_audio(struct sbc_encoder_state *state, struct sbc_frame *frame)
@@ -1026,8 +1305,6 @@
 	case 8:
 		for (ch = 0; ch < frame->channels; ch++)
 			for (blk = 0; blk < frame->blocks; blk++) {
-				memset(frame->sb_sample[blk][ch], 0,
-					sizeof(frame->sb_sample[blk][ch]));
 				sbc_analyze_eight(state, frame, ch, blk);
 			}
 
@@ -1066,7 +1343,7 @@
 	int bits[2][8];		/* bits distribution */
 	int levels[2][8];	/* levels are derived from that */
 
-	double scalefactor[2][8];	/* derived from frame->scale_factor */
+	u_int32_t scalefactor[2][8];	/* derived from frame->scale_factor */
 
 	if (len < 4) {
 		return -1;
@@ -1077,16 +1354,16 @@
 
 	data[0] = SBC_SYNCWORD;
 
-	if (frame->sampling_frequency == 16) {
+	if (frame->sampling_frequency == 16000) {
 		data[1] |= (SBC_FS_16 & 0x03) << 6;
 		sf = SBC_FS_16;
-	} else if (frame->sampling_frequency == 32) {
+	} else if (frame->sampling_frequency == 32000) {
 		data[1] |= (SBC_FS_32 & 0x03) << 6;
 		sf = SBC_FS_32;
-	} else if (frame->sampling_frequency == 44.1) {
+	} else if (frame->sampling_frequency == 44100) {
 		data[1] |= (SBC_FS_44 & 0x03) << 6;
 		sf = SBC_FS_44;
-	} else if (frame->sampling_frequency == 48) {
+	} else if (frame->sampling_frequency == 48000) {
 		data[1] |= (SBC_FS_48 & 0x03) << 6;
 		sf = SBC_FS_48;
 	} else {
@@ -1149,7 +1426,11 @@
 			frame->scale_factor[ch][sb] = 0;
 			scalefactor[ch][sb] = 2;
 			for (blk = 0; blk < frame->blocks; blk++) {
+#ifdef USE_FIXED
+				while (scalefactor[ch][sb] < fabs(frame->sb_sample_f[blk][ch][sb])) {
+#else
 				while (scalefactor[ch][sb] < fabs(frame->sb_sample[blk][ch][sb])) {
+#endif
 					frame->scale_factor[ch][sb]++;
 					scalefactor[ch][sb] *= 2;
 				}
@@ -1252,9 +1533,15 @@
 		for (ch = 0; ch < frame->channels; ch++) {
 			for (sb = 0; sb < frame->subbands; sb++) {
 				if (levels[ch][sb] > 0) {
+#ifdef USE_FIXED
+					frame->audio_sample[blk][ch][sb] =
+						(u_int16_t) ((((frame->sb_sample_f[blk][ch][sb]*levels[ch][sb]) >> (frame->scale_factor[ch][sb] + 1)) +
+						levels[ch][sb]) >> 1);
+#else
 					frame->audio_sample[blk][ch][sb] =
-					    (u_int16_t) (((frame->sb_sample[blk][ch][sb] / scalefactor[ch][sb] +
-							   1.0) * levels[ch][sb]) / 2.0);
+						(u_int16_t) (((frame->sb_sample[blk][ch][sb] / scalefactor[ch][sb] +
+						1.0) * levels[ch][sb]) / 2.0);
+#endif
 				} else {
 					frame->audio_sample[blk][ch][sb] = 0;
 				}
@@ -1339,7 +1626,7 @@
 		sbc_decoder_init(&priv->dec_state, &priv->frame);
 		priv->init = 1;
 
-		sbc->rate = priv->frame.sampling_frequency * 1000;
+		sbc->rate = priv->frame.sampling_frequency;
 		sbc->channels = priv->frame.channels;
 		sbc->subbands = priv->frame.subbands;
 		sbc->blocks = priv->frame.blocks;
@@ -1367,11 +1654,11 @@
 
 	for (i = 0; i < samples; i++) {
 		for (ch = 0; ch < priv->frame.channels; ch++) {
-			uint16_t s;
+			int16_t s;
 #ifdef USE_FIXED
 			s = (uint16_t)fixedtoi(priv->frame.pcm_sample_f[ch][i]);
 #else
-			s = (uint16_t)(priv->frame.pcm_sample[ch][i]);
+			s = priv->frame.pcm_sample[ch][i];
 #endif
 			*ptr++ = (s & 0xff00) >> 8;
 			*ptr++ = (s & 0x00ff);
@@ -1397,7 +1684,7 @@
 	priv = sbc->priv;
 
 	if (!priv->init) {
-		priv->frame.sampling_frequency = ((double) sbc->rate) / 1000;
+		priv->frame.sampling_frequency = sbc->rate;
 		
 		priv->frame.channels = sbc->channels;
 
@@ -1420,7 +1707,7 @@
 		for (ch = 0; ch < sbc->channels; ch++) {
 			int16_t s = (ptr[0] & 0xff) << 8 | (ptr[1] & 0xff);
 			ptr += 2;
-			priv->frame.pcm_sample[ch][i] = ((double) s);
+			priv->frame.pcm_sample[ch][i] = s;
 		}
 	}
 
Index: sbc/sbc.h
===================================================================
RCS file: /cvsroot/bluetooth-alsa/btsco/sbc/sbc.h,v
retrieving revision 1.20
diff -u -r1.20 sbc.h
--- sbc/sbc.h	4 Jul 2005 03:56:51 -0000	1.20
+++ sbc/sbc.h	21 Aug 2005 18:26:32 -0000
@@ -97,6 +97,44 @@
 
 //overflow problems?
 //static inline sbc_fixed_t fxdiv(sbc_fixed_t a, sbc_fixed_t b) { return (a<<FRAC)/b; }
+
+#define ADD64(dhi, dlo, shi, slo)  { dlo += slo; dhi += shi; if ( (unsigned long)dlo < (unsigned long)slo ) dhi++;}
+#define SUB64(dhi, dlo, shi, slo)  { dlo -= slo; dhi -= shi; if ( (unsigned long)dlo > (unsigned long)slo ) dhi--;}
+
+#ifdef USE_FIXED_ARM
+// arm specific (should be fast on arm)
+
+#define MUL64(hi, lo, x, y) \
+    asm ("smull	%0, %1, %2, %3"  \
+	 : "=&r" (lo), "=&r" (hi)  \
+	 : "%r" (x), "r" (y))
+
+#define MULA64(hi, lo, x, y)  \
+    asm ("smlal	%0, %1, %2, %3"  \
+	 : "+r" (lo), "+r" (hi)  \
+	 : "%r" (x), "r" (y))
+
+#define SCALE64(hi, lo, bits) \
+    ({ int32_t __result;  \
+    asm ("movs	%0, %1, lsr %3\n\t"  \
+	 "adc	%0, %0, %2, lsl %4"  \
+	 : "=&r" (__result)  \
+	 : "r" (lo), "r" (hi), \
+	 "M" (bits), "M" (32 - bits)  \
+	 : "cc");  \
+    __result;  \
+    })
+
+#else
+//general purpose (slow?)
+
+#define MUL64(hi, lo, a, b) {long long x; x = (long long)a * b; hi = (long)(x >> 32); lo = (long)x;}
+#define MULA64(hi, lo, a, b)  {long long x; x = (long long)a * b; hi += (long)(x >> 32); lo += (long)x; if ((unsigned long)lo < (unsigned long)x) hi++;}
+#define SCALE64(hi, lo, bits) ((int32_t)((hi << (32 - bits)) | ((lo >> bits) & (0xFFFFFFFF >> bits))))
+
+#endif
+
+
 #endif
 
 int sbc_init(sbc_t *sbc, unsigned long flags);
Index: sbc/sbc_tables.h
===================================================================
RCS file: /cvsroot/bluetooth-alsa/btsco/sbc/sbc_tables.h,v
retrieving revision 1.2
diff -u -r1.2 sbc_tables.h
--- sbc/sbc_tables.h	24 Nov 2004 06:45:21 -0000	1.2
+++ sbc/sbc_tables.h	21 Aug 2005 18:26:32 -0000
@@ -175,4 +175,19 @@
 	  -0.382683432365091,  0.555570233019606, -0.707106781186548,  0.831469612302547 }
 };
 
+static const float _anamatrix8[8] = {
+	0.923879532511287, 0.382683432365091, 0.980785280403231, 0.831469612302547, 0.555570233019602,
+	0.195090322016128, 0.707106781186547, 1
+};
+
+static const float _sbc_proto_8[40] = {
+	5.65949455E-03, 6.79989457E-02, 8.23919487E-04, 1.46525260E-02, 1.23264551E-01,-1.46404076E-02,
+	3.43256426E-04, 1.04584442E-02, 9.75753888E-02, -3.90751399E-02, -1.64973096E-03, 1.56575392E-04,
+	8.02941155E-03, 8.29847604E-02, -5.31873032E-02, -3.49717448E-03, 5.54620230E-04, 1.27472337E-02,
+	1.11196689E-01, -2.61098761E-02, -1.78805363E-04, 1.13992509E-03, 1.59045607E-02, 1.33264422E-01,
+	-4.91578039E-03, 1.61656283E-03, 1.47640170E-03, 1.62208471E-02, 1.40753508E-01, 2.92408443E-03,
+	1.99454557E-03, 1.78371731E-03, 1.53184105E-02, 1.45389840E-01, 8.85757525E-03, 2.10371986E-03,
+	2.01182533E-03, 1.29371807E-02, 1.46955073E-01, 9.02154483E-04
+};
+
 #endif /* __SBC_TABLES_H */
Index: sbc/sbc_tables_f.h
===================================================================
RCS file: /cvsroot/bluetooth-alsa/btsco/sbc/sbc_tables_f.h,v
retrieving revision 1.6
diff -u -r1.6 sbc_tables_f.h
--- sbc/sbc_tables_f.h	4 Jul 2005 03:56:51 -0000	1.6
+++ sbc/sbc_tables_f.h	21 Aug 2005 18:26:32 -0000
@@ -1,77 +1,72 @@
 static const sbc_fixed_t sbc_proto_4_40_f[40] = {
-0x00000000, 0x00000232, 0x0000061c, 0x00000b32, 0x00000fb7, 0x00000ff1, 0x000007a4, 0xfffff378, 
-0x00002cb3, 0x000053b7, 0x00007646, 0x000083dd, 0x000069fd, 0x0000191e, 0xffff89f3, 0xfffec1f6, 
-0x00022b63, 0x00031eab, 0x0003f239, 0x0004825e, 0x0004b584, 0x0004825e, 0x0003f239, 0x00031eab, 
-0xfffdd49d, 0xfffec1f6, 0xffff89f3, 0x0000191e, 0x000069fd, 0x000083dd, 0x00007646, 0x000053b7, 
-0xffffd34d, 0xfffff378, 0x000007a4, 0x00000ff1, 0x00000fb7, 0x00000b32, 0x0000061c, 0x00000232
+0x00000000, 0x0002329d, 0x00061c5a, 0x000b3280, 0x000fb799, 0x000ff11d, 0x0007a473, 0xfff3773a, 
+0x002cb3e9, 0x0053b755, 0x00764668, 0x0083ddc8, 0x0069fdc6, 0x00191e58, 0xff89f23a, 0xfec1f5e6, 
+0x022b63dc, 0x031eab94, 0x03f23948, 0x04825e48, 0x04b58400, 0x04825e48, 0x03f23948, 0x031eab94, 
+0xfdd49c24, 0xfec1f5e6, 0xff89f23a, 0x00191e58, 0x0069fdc6, 0x0083ddc8, 0x00764668, 0x0053b755, 
+0xffd34c17, 0xfff3773a, 0x0007a473, 0x000ff11d, 0x000fb799, 0x000b3280, 0x00061c5a, 0x0002329d
 };
 
 static const sbc_fixed_t sbc_proto_8_80_f[80] = {
-0x00000000, 0x000000a4, 0x00000167, 0x00000245, 0x0000035f, 0x000004ab, 0x0000060c, 0x0000074e, 
-0x0000083d, 0x0000089d, 0x0000082b, 0x0000069f, 0x000003b1, 0xffffff45, 0xfffff93f, 0xfffff1ad, 
-0x0000172e, 0x000020e3, 0x00002ad6, 0x00003436, 0x00003c04, 0x00004125, 0x00004270, 0x00003ebe, 
-0x000034fd, 0x00002447, 0x00000bfa, 0xffffebde, 0xffffc409, 0xffff950e, 0xffff5ff3, 0xffff2626, 
-0x00011686, 0x000153e7, 0x00018fab, 0x0001c776, 0x0001f8e4, 0x000221d9, 0x00024086, 0x00025384, 
-0x000259ed, 0x00025384, 0x00024086, 0x000221d9, 0x0001f8e4, 0x0001c776, 0x00018fab, 0x000153e7, 
-0xfffee97a, 0xffff2626, 0xffff5ff3, 0xffff950e, 0xffffc409, 0xffffebde, 0x00000bfa, 0x00002447, 
-0x000034fd, 0x00003ebe, 0x00004270, 0x00004125, 0x00003c04, 0x00003436, 0x00002ad6, 0x000020e3, 
-0xffffe8d2, 0xfffff1ad, 0xfffff93f, 0xffffff45, 0x000003b1, 0x0000069f, 0x0000082b, 0x0000089d, 
-0x0000083d, 0x0000074e, 0x0000060c, 0x000004ab, 0x0000035f, 0x00000245, 0x00000167, 0x000000a4
+0x00000000, 0x0000a42e, 0x000167ee, 0x00024590, 0x00035ff1, 0x0004ab4c, 0x00060c1f, 0x00074e5d, 
+0x00083d8d, 0x00089de9, 0x00082b6f, 0x00069f17, 0x0003b1fa, 0xffff4482, 0xfff93e22, 0xfff1acf2, 
+0x00172e69, 0x0020e373, 0x002ad679, 0x00343672, 0x003c044a, 0x00412524, 0x004270cb, 0x003ebe85, 
+0x0034fd9e, 0x002447d7, 0x000bfa20, 0xffebdd6e, 0xffc4086b, 0xff950dcf, 0xff5ff2bf, 0xff262512, 
+0x01168610, 0x0153e7d4, 0x018fab36, 0x01c7762e, 0x01f8e440, 0x0221d9e0, 0x024086c0, 0x0253844c, 
+0x0259ed90, 0x0253844c, 0x024086c0, 0x0221d9e0, 0x01f8e440, 0x01c7762e, 0x018fab36, 0x0153e7d4, 
+0xfee979f0, 0xff262512, 0xff5ff2bf, 0xff950dcf, 0xffc4086b, 0xffebdd6e, 0x000bfa20, 0x002447d7, 
+0x0034fd9e, 0x003ebe85, 0x004270cb, 0x00412524, 0x003c044a, 0x00343672, 0x002ad679, 0x0020e373, 
+0xffe8d197, 0xfff1acf2, 0xfff93e22, 0xffff4482, 0x0003b1fa, 0x00069f17, 0x00082b6f, 0x00089de9, 
+0x00083d8d, 0x00074e5d, 0x00060c1f, 0x0004ab4c, 0x00035ff1, 0x00024590, 0x000167ee, 0x0000a42e
 };
 
 static const sbc_fixed_t synmatrix4_f[8][4] = {
-{ 0x000b504f, 0xfff4afb1, 0xfff4afb1, 0x000b504f },
-{ 0x00061f78, 0xfff137cb, 0x000ec835, 0xfff9e088 },
+{ 0x0b504f30, 0xf4afb0d0, 0xf4afb0d0, 0x0b504f30 },
+{ 0x061f78a8, 0xf137ca20, 0x0ec835e0, 0xf9e08758 },
 { 0x00000000, 0x00000000, 0x00000000, 0x00000000 },
-{ 0xfff9e088, 0x000ec835, 0xfff137cb, 0x00061f78 },
-{ 0xfff4afb1, 0x000b504f, 0x000b504f, 0xfff4afb1 },
-{ 0xfff137cb, 0xfff9e088, 0x00061f78, 0x000ec835 },
-{ 0xfff00000, 0xfff00000, 0xfff00000, 0xfff00000 },
-{ 0xfff137cb, 0xfff9e088, 0x00061f78, 0x000ec835 }
+{ 0xf9e08758, 0x0ec835e0, 0xf137ca20, 0x061f78a8 },
+{ 0xf4afb0d0, 0x0b504f30, 0x0b504f30, 0xf4afb0d0 },
+{ 0xf137ca20, 0xf9e08758, 0x061f78a8, 0x0ec835e0 },
+{ 0xf0000000, 0xf0000000, 0xf0000000, 0xf0000000 },
+{ 0xf137ca20, 0xf9e08758, 0x061f78a8, 0x0ec835e0 }
 };
 
 static const sbc_fixed_t synmatrix8_f[16][8] = {
-{ 0x000b504f, 0xfff4afb1, 0xfff4afb1, 0x000b504f, 0x000b504f, 0xfff4afb1, 0xfff4afb1, 0x000b504f },
-{ 0x0008e39d, 0xfff04eb5, 0x00031f17, 0x000d4db3, 0xfff2b24d, 0xfffce0e9, 0x000fb14b, 0xfff71c63 },
-{ 0x00061f78, 0xfff137cb, 0x000ec835, 0xfff9e088, 0xfff9e088, 0x000ec835, 0xfff137cb, 0x00061f78 },
-{ 0x00031f17, 0xfff71c63, 0x000d4db3, 0xfff04eb5, 0x000fb14b, 0xfff2b24d, 0x0008e39d, 0xfffce0e9 },
+{ 0x0b504f30, 0xf4afb0d0, 0xf4afb0d0, 0x0b504f30, 0x0b504f30, 0xf4afb0d0, 0xf4afb0d0, 0x0b504f30 },
+{ 0x08e39da0, 0xf04eb420, 0x031f1708, 0x0d4db310, 0xf2b24cf0, 0xfce0e8f8, 0x0fb14be0, 0xf71c6260 },
+{ 0x061f78a8, 0xf137ca20, 0x0ec835e0, 0xf9e08758, 0xf9e08758, 0x0ec835e0, 0xf137ca20, 0x061f78a8 },
+{ 0x031f1708, 0xf71c6260, 0x0d4db310, 0xf04eb420, 0x0fb14be0, 0xf2b24cf0, 0x08e39da0, 0xfce0e8f8 },
 { 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 },
-{ 0xfffce0e9, 0x0008e39d, 0xfff2b24d, 0x000fb14b, 0xfff04eb5, 0x000d4db3, 0xfff71c63, 0x00031f17 },
-{ 0xfff9e088, 0x000ec835, 0xfff137cb, 0x00061f78, 0x00061f78, 0xfff137cb, 0x000ec835, 0xfff9e088 },
-{ 0xfff71c63, 0x000fb14b, 0xfffce0e9, 0xfff2b24d, 0x000d4db3, 0x00031f17, 0xfff04eb5, 0x0008e39d },
-{ 0xfff4afb1, 0x000b504f, 0x000b504f, 0xfff4afb1, 0xfff4afb1, 0x000b504f, 0x000b504f, 0xfff4afb1 },
-{ 0xfff2b24d, 0x00031f17, 0x000fb14b, 0x0008e39d, 0xfff71c63, 0xfff04eb5, 0xfffce0e9, 0x000d4db3 },
-{ 0xfff137cb, 0xfff9e088, 0x00061f78, 0x000ec835, 0x000ec835, 0x00061f78, 0xfff9e088, 0xfff137cb },
-{ 0xfff04eb5, 0xfff2b24d, 0xfff71c63, 0xfffce0e9, 0x00031f17, 0x0008e39d, 0x000d4db3, 0x000fb14b },
-{ 0xfff00000, 0xfff00000, 0xfff00000, 0xfff00000, 0xfff00000, 0xfff00000, 0xfff00000, 0xfff00000 },
-{ 0xfff04eb5, 0xfff2b24d, 0xfff71c63, 0xfffce0e9, 0x00031f17, 0x0008e39d, 0x000d4db3, 0x000fb14b },
-{ 0xfff137cb, 0xfff9e088, 0x00061f78, 0x000ec835, 0x000ec835, 0x00061f78, 0xfff9e088, 0xfff137cb },
-{ 0xfff2b24d, 0x00031f17, 0x000fb14b, 0x0008e39d, 0xfff71c63, 0xfff04eb5, 0xfffce0e9, 0x000d4db3 }
+{ 0xfce0e8f8, 0x08e39da0, 0xf2b24cf0, 0x0fb14be0, 0xf04eb420, 0x0d4db310, 0xf71c6260, 0x031f1708 },
+{ 0xf9e08758, 0x0ec835e0, 0xf137ca20, 0x061f78a8, 0x061f78a8, 0xf137ca20, 0x0ec835e0, 0xf9e08758 },
+{ 0xf71c6260, 0x0fb14be0, 0xfce0e8f8, 0xf2b24cf0, 0x0d4db310, 0x031f1708, 0xf04eb420, 0x08e39da0 },
+{ 0xf4afb0d0, 0x0b504f30, 0x0b504f30, 0xf4afb0d0, 0xf4afb0d0, 0x0b504f30, 0x0b504f30, 0xf4afb0d0 },
+{ 0xf2b24cf0, 0x031f1708, 0x0fb14be0, 0x08e39da0, 0xf71c6260, 0xf04eb420, 0xfce0e8f8, 0x0d4db310 },
+{ 0xf137ca20, 0xf9e08758, 0x061f78a8, 0x0ec835e0, 0x0ec835e0, 0x061f78a8, 0xf9e08758, 0xf137ca20 },
+{ 0xf04eb420, 0xf2b24cf0, 0xf71c6260, 0xfce0e8f8, 0x031f1708, 0x08e39da0, 0x0d4db310, 0x0fb14be0 },
+{ 0xf0000000, 0xf0000000, 0xf0000000, 0xf0000000, 0xf0000000, 0xf0000000, 0xf0000000, 0xf0000000 },
+{ 0xf04eb420, 0xf2b24cf0, 0xf71c6260, 0xfce0e8f8, 0x031f1708, 0x08e39da0, 0x0d4db310, 0x0fb14be0 },
+{ 0xf137ca20, 0xf9e08758, 0x061f78a8, 0x0ec835e0, 0x0ec835e0, 0x061f78a8, 0xf9e08758, 0xf137ca20 },
+{ 0xf2b24cf0, 0x031f1708, 0x0fb14be0, 0x08e39da0, 0xf71c6260, 0xf04eb420, 0xfce0e8f8, 0x0d4db310 }
 };
 
 static const sbc_fixed_t anamatrix4_f[4][8] = {
-{ 0x000b504f, 0x000ec835, 0x00100000, 0x000ec835, 0x000b504f, 0x00061f78, 0x00000000, 0xfff9e088 },
-{ 0xfff4afb1, 0x00061f78, 0x00100000, 0x00061f78, 0xfff4afb1, 0xfff137cb, 0x00000000, 0x000ec835 },
-{ 0xfff4afb1, 0xfff9e088, 0x00100000, 0xfff9e088, 0xfff4afb1, 0x000ec835, 0x00000000, 0xfff137cb },
-{ 0x000b504f, 0xfff137cb, 0x00100000, 0xfff137cb, 0x000b504f, 0xfff9e088, 0x00000000, 0x00061f78 }
-};
-
-static const sbc_fixed_t anamatrix8_f[8][16] = {
-{ 0x000ec835, 0x000fb14b, 0x00100000, 0x000fb14b, 0x000ec835, 0x000d4db3, 0x000b504f, 0x0008e39d, 
-0x00061f78, 0x00031f17, 0x00000000, 0xfffce0e9, 0xfff9e088, 0xfff71c63, 0xfff4afb1, 0xfff2b24d },
-{ 0x00061f78, 0x000d4db3, 0x00100000, 0x000d4db3, 0x00061f78, 0xfffce0e9, 0xfff4afb1, 0xfff04eb5, 
-0xfff137cb, 0xfff71c63, 0x00000000, 0x0008e39d, 0x000ec835, 0x000fb14b, 0x000b504f, 0x00031f17 },
-{ 0xfff9e088, 0x0008e39d, 0x00100000, 0x0008e39d, 0xfff9e088, 0xfff04eb5, 0xfff4afb1, 0x00031f17, 
-0x000ec835, 0x000d4db3, 0x00000000, 0xfff2b24d, 0xfff137cb, 0xfffce0e9, 0x000b504f, 0x000fb14b },
-{ 0xfff137cb, 0x00031f17, 0x00100000, 0x00031f17, 0xfff137cb, 0xfff71c63, 0x000b504f, 0x000d4db3, 
-0xfff9e088, 0xfff04eb5, 0x00000000, 0x000fb14b, 0x00061f78, 0xfff2b24d, 0xfff4afb1, 0x0008e39d },
-{ 0xfff137cb, 0xfffce0e9, 0x00100000, 0xfffce0e9, 0xfff137cb, 0x0008e39d, 0x000b504f, 0xfff2b24d, 
-0xfff9e088, 0x000fb14b, 0x00000000, 0xfff04eb5, 0x00061f78, 0x000d4db3, 0xfff4afb1, 0xfff71c63 },
-{ 0xfff9e088, 0xfff71c63, 0x00100000, 0xfff71c63, 0xfff9e088, 0x000fb14b, 0xfff4afb1, 0xfffce0e9, 
-0x000ec835, 0xfff2b24d, 0x00000000, 0x000d4db3, 0xfff137cb, 0x00031f17, 0x000b504f, 0xfff04eb5 },
-{ 0x00061f78, 0xfff2b24d, 0x00100000, 0xfff2b24d, 0x00061f78, 0x00031f17, 0xfff4afb1, 0x000fb14b, 
-0xfff137cb, 0x0008e39d, 0x00000000, 0xfff71c63, 0x000ec835, 0xfff04eb5, 0x000b504f, 0xfffce0e9 },
-{ 0x000ec835, 0xfff04eb5, 0x00100000, 0xfff04eb5, 0x000ec835, 0xfff2b24d, 0x000b504f, 0xfff71c63, 
-0x00061f78, 0xfffce0e9, 0x00000000, 0x00031f17, 0xfff9e088, 0x0008e39d, 0xfff4afb1, 0x000d4db3 }
+{ 0x0b504f30, 0x0ec835e0, 0x10000000, 0x0ec835e0, 0x0b504f30, 0x061f78a8, 0x00000000, 0xf9e08758 },
+{ 0xf4afb0d0, 0x061f78a8, 0x10000000, 0x061f78a8, 0xf4afb0d0, 0xf137ca20, 0x00000000, 0x0ec835e0 },
+{ 0xf4afb0d0, 0xf9e08758, 0x10000000, 0xf9e08758, 0xf4afb0d0, 0x0ec835e0, 0x00000000, 0xf137ca20 },
+{ 0x0b504f30, 0xf137ca20, 0x10000000, 0xf137ca20, 0x0b504f30, 0xf9e08758, 0x00000000, 0x061f78a8 }
+};
+
+#define FIXED64_STAGE1 24
+static const int32_t _sbc_proto_8_f[40] = {
+0x02e5cd20, 0x22d0c200, 0x006bfe27, 0x07808930, 0x3f1c8800, 0xf8810d70, 0x002cfdc6, 0x055acf28, 
+0x31f566c0, 0xebfe57e0, 0xff27c437, 0x001485cc, 0x041c6e58, 0x2a7cfa80, 0xe4c4a240, 0xfe359e4c, 
+0x0048b1f8, 0x0686ce30, 0x38eec5c0, 0xf2a1b9f0, 0xffe8904a, 0x0095698a, 0x0824a480, 0x443b3c00, 
+0xfd7badc8, 0x00d3e2d9, 0x00c183d2, 0x084e1950, 0x4810d800, 0x017f43fe, 0x01056dd8, 0x00e9cb9f, 
+0x07d7d090, 0x4a708980, 0x0488fae8, 0x0113bd20, 0x0107b1a8, 0x069fb3c0, 0x4b3db200, 0x00763f48
+};
+
+#define FIXED64_STAGE2 7
+static const int32_t _anamatrix8_f[8] = {
+0x3b20d780, 0x187de2a0, 0x3ec52f80, 0x3536cc40, 0x238e7680, 0x0c7c5c20, 0x2d413cc0, 0x40000000
 };
 
Index: sbc/sbcdec.c
===================================================================
RCS file: /cvsroot/bluetooth-alsa/btsco/sbc/sbcdec.c,v
retrieving revision 1.5
diff -u -r1.5 sbcdec.c
--- sbc/sbcdec.c	1 May 2005 16:36:44 -0000	1.5
+++ sbc/sbcdec.c	21 Aug 2005 18:26:32 -0000
@@ -40,7 +40,7 @@
 
 #define BUF_SIZE 2048
 
-static void decode(char *filename, char *audiodevice)
+static void decode(char *filename, char *audiodevice, int tofile)
 {
 	unsigned char buf[BUF_SIZE], *stream;
 	struct stat st;
@@ -82,7 +82,7 @@
 	pos = 0;
 	streamlen = st.st_size;
 
-	ad = open(audiodevice, O_WRONLY, 0);
+	ad = open(audiodevice, O_WRONLY | (tofile ? (O_CREAT | O_TRUNC) : 0), tofile ? 0644 : 0);
 	if (ad < 0) {
 		fprintf(stderr, "Can't open audio device %s: %s\n",
 						audiodevice, strerror(errno));
@@ -93,25 +93,25 @@
 
 	framelen = sbc_decode(&sbc, stream, streamlen);
 	printf("%d Hz, %d channels\n", sbc.rate, sbc.channels);
+	if (!tofile) {
+		if (ioctl(ad, SNDCTL_DSP_SETFMT, &format) < 0) {
+			fprintf(stderr, "Can't set audio format on %s: %s\n",
+							audiodevice, strerror(errno));
+			goto close;
+		}
 
-	if (ioctl(ad, SNDCTL_DSP_SETFMT, &format) < 0) {
-		fprintf(stderr, "Can't set audio format on %s: %s\n",
-						audiodevice, strerror(errno));
-		goto close;
-	}
-
-	if (ioctl(ad, SNDCTL_DSP_CHANNELS, &sbc.channels) < 0) {
-		fprintf(stderr, "Can't set number of channels on %s: %s\n",
-						audiodevice, strerror(errno));
-		goto close;
-	}
+		if (ioctl(ad, SNDCTL_DSP_CHANNELS, &sbc.channels) < 0) {
+			fprintf(stderr, "Can't set number of channels on %s: %s\n",
+							audiodevice, strerror(errno));
+			goto close;
+		}
 
-	if (ioctl(ad, SNDCTL_DSP_SPEED, &sbc.rate) < 0) {
-		fprintf(stderr, "Can't set audio rate on %s: %s\n",
-						audiodevice, strerror(errno));
-		goto close;
+		if (ioctl(ad, SNDCTL_DSP_SPEED, &sbc.rate) < 0) {
+			fprintf(stderr, "Can't set audio rate on %s: %s\n",
+							audiodevice, strerror(errno));
+			goto close;
+		}
 	}
-
 	count = 0;
 
 	while (framelen > 0) {
@@ -152,6 +152,7 @@
 		"\t-h, --help           Display help\n"
 		"\t-d, --device <dsp>   Sound device\n"
 		"\t-v, --verbose        Verbose mode\n"
+		"\t-f, --file           Decode to a file\n"
 		"\n");
 }
 
@@ -159,15 +160,17 @@
 	{ "help",	0, 0, 'h' },
 	{ "device",	1, 0, 'd' },
 	{ "verbose",	0, 0, 'v' },
+	{ "file",	1, 0, 'f' },
 	{ 0, 0, 0, 0 }
 };
 
 int main(int argc, char *argv[])
 {
 	char *device = NULL;
-	int i, opt, verbose = 0;
+	char *file = NULL;
+	int i, opt, verbose = 0, tofile = 0;
 
-	while ((opt = getopt_long(argc, argv, "+hd:v", main_options, NULL)) != -1) {
+	while ((opt = getopt_long(argc, argv, "+hd:vf:", main_options, NULL)) != -1) {
 		switch(opt) {
 		case 'h':
 			usage();
@@ -180,6 +183,10 @@
 		case 'v':
 			verbose = 1;
 			break;
+		case 'f' :
+			file = strdup(optarg);
+			tofile = 1;
+			break;
 
 		default:
 			exit(1);
@@ -196,7 +203,7 @@
 	}
 
 	for (i = 0; i < argc; i++)
-		decode(argv[i], device ? device : "/dev/dsp");
+		decode(argv[i], device ? device : file ? file : "/dev/dsp", tofile);
 
 	if (device)
 		free(device);

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

[Roberto]

Thanks Victor I will also try to port to Symbian devices to see the
improvements ...Ciao Roberto

----- Original Message ----- 
From: "Victor Shcherbatyuk" <victor@win.tue.nl>
To: <bluez-devel@lists.sourceforge.net>
Sent: Sunday, August 21, 2005 8:47 PM
Subject: Re: [Bluez-devel] sbc and fixed-point progress


> Hello Brad,
>
> In the attachment is the patch to support fixed point encoding for
8-subband
> sbc codec. To compie ARM specific version USE_FIXED_ARM should be defined
> (currently in sbc/sbc.c should be in configuration?). It is possible I
broke
> your fixed point tables cause I've changed gen_fixed.c, but it should be
> easy fixable.
>
> Floating point implementation is optimized too, runs 30% faster on my
> AthlonXP. General fixed point (long long) runs slower than floating on my
> PC, which is strange... I do not have HW to test arm specific version real
> time, hope no suprises there, but I could have missed something when
> integrating it into sbc code (it decodes well, but how fast, I will try
only
> monday evening).
>
> Using a2play needs to tweak 87 magic number, otherwise it drops samples?
>
> Regards,
>      Victor.
>
> P.S. There are a lot of changes, I hope I didn't miss any... Please take a
> look, and let me know if something is wrong with it...
>
> ----- 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

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

[Victor Shcherbatyuk]

It might be that 32 bit implementation will suffice, cause the one I did 
some time before had some flaws, I will try to do it again some time later. 
For 64-bit arithmetics (MUL64 , MULA64 defines) you can look at libmad, they 
have it for many platforms and probably it will be more efficient. Most of 
inefficiency now is probably outside of synthesis filter (memcopies and so 
on)...

Victor.

----- Original Message ----- 
From: "Roberto" <rlr@bitween.com>
To: <bluez-devel@lists.sourceforge.net>
Sent: Sunday, August 21, 2005 23:56
Subject: Re: [Bluez-devel] sbc and fixed-point progress


> Thanks Victor I will also try to port to Symbian devices to see the
> improvements ...Ciao Roberto
>
> ----- Original Message ----- 
> From: "Victor Shcherbatyuk" <victor@win.tue.nl>
> To: <bluez-devel@lists.sourceforge.net>
> Sent: Sunday, August 21, 2005 8:47 PM
> Subject: Re: [Bluez-devel] sbc and fixed-point progress
>
>
>> Hello Brad,
>>
>> In the attachment is the patch to support fixed point encoding for
> 8-subband
>> sbc codec. To compie ARM specific version USE_FIXED_ARM should be defined
>> (currently in sbc/sbc.c should be in configuration?). It is possible I
> broke
>> your fixed point tables cause I've changed gen_fixed.c, but it should be
>> easy fixable.
>>
>> Floating point implementation is optimized too, runs 30% faster on my
>> AthlonXP. General fixed point (long long) runs slower than floating on my
>> PC, which is strange... I do not have HW to test arm specific version 
>> real
>> time, hope no suprises there, but I could have missed something when
>> integrating it into sbc code (it decodes well, but how fast, I will try
> only
>> monday evening).
>>
>> Using a2play needs to tweak 87 magic number, otherwise it drops samples?
>>
>> Regards,
>>      Victor.
>>
>> P.S. There are a lot of changes, I hope I didn't miss any... Please take 
>> a
>> look, and let me know if something is wrong with it...
>>
>> ----- 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

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

[Brad Midgley]

Victor

> In the attachment is the patch to support fixed point encoding for 

This is great! If everything works I'm going to commit it as-is and we 
can tweak it later for 4 subbands etc.

> 8-subband sbc codec. To compie ARM specific version USE_FIXED_ARM should 
> be defined (currently in sbc/sbc.c should be in configuration?). It is 

If it seems ok, I'd like to just use '#ifdef __arm__' so it's automatic.

> possible I broke your fixed point tables cause I've changed gen_fixed.c, 
> but it should be easy fixable.

ok, the change should be fine

> Floating point implementation is optimized too, runs 30% faster on my 

wow, nice. Maybe this room for optimization is what Marcel was talking 
about.

> AthlonXP. General fixed point (long long) runs slower than floating on 
> my PC, which is strange...

interesting

> I do not have HW to test arm specific version 
> real time, hope no suprises there, but I could have missed something 
> when integrating it into sbc code (it decodes well, but how fast, I will 
> try only monday evening).

Ok, I'll load it on gumstix now and give it a try.

> Using a2play needs to tweak 87 magic number, otherwise it drops samples?

yes, this is disappointing. We may need to find another way to get 
reliable timing than setitimer.

I did change the first usleep(10) to usleep(1000) and that *may* help 
with this problem by ensuring that we always interrupt the usleep 
syscall consistently. I don't have my hp headphones (the set that's very 
sensitive to timing) handy to test.

Brad


-------------------------------------------------------
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

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

[Brad Midgley]

Victor

>> I do not have HW to test arm specific version real time, hope no 
>> suprises there, but I could have missed something when integrating it 
>> into sbc code (it decodes well, but how fast, I will try only monday 
>> evening).
> 
> 
> Ok, I'll load it on gumstix now and give it a try.

This is almost perfect. On a 400mhz gumstix (pxa255), I'm able to send a 
5-minute audio stream with only about three breaks in the audio (about 5 
seconds each).

I think it will work flawlessly in 4 subbands or if we can shorten a few 
of the ops from 64 to 32 bit.

I committed what's there and used __arm__ for the conditional asm code.

>> Using a2play needs to tweak 87 magic number, otherwise it drops samples?
> 
> 
> yes, this is disappointing. We may need to find another way to get 
> reliable timing than setitimer.
> 
> I did change the first usleep(10) to usleep(1000) and that *may* help 
> with this problem by ensuring that we always interrupt the usleep 
> syscall consistently. I don't have my hp headphones (the set that's very 
> sensitive to timing) handy to test.

fwiw, I had to use the -n flag to a2play so it wouldn't use itimer at 
all. This flag tells a2play to just send the audio as fast as it can 
encode it.

Brad


-------------------------------------------------------
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

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

[Victor Shcherbatyuk]

[-- Attachment #1: Type: text/plain, Size: 2350 bytes --]

Hello Brad,

I did some test runs on ARM9@400MHz, general fixed point encoder eats up ~40% of CPU time, while arm specific version  - ~20%. And in both cases it runs quite smooth. So the drops you had should have been caused by something else (unless you run some othe applications cuncurently).


Victor.


-----Original Message-----
From: bluez-devel-admin@lists.sourceforge.net on behalf of Brad Midgley
Sent: Mon 8/22/2005 9:22 AM
To: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] sbc and fixed-point progress
 
Victor

>> I do not have HW to test arm specific version real time, hope no 
>> suprises there, but I could have missed something when integrating it 
>> into sbc code (it decodes well, but how fast, I will try only monday 
>> evening).
> 
> 
> Ok, I'll load it on gumstix now and give it a try.

This is almost perfect. On a 400mhz gumstix (pxa255), I'm able to send a 
5-minute audio stream with only about three breaks in the audio (about 5 
seconds each).

I think it will work flawlessly in 4 subbands or if we can shorten a few 
of the ops from 64 to 32 bit.

I committed what's there and used __arm__ for the conditional asm code.

>> Using a2play needs to tweak 87 magic number, otherwise it drops samples?
> 
> 
> yes, this is disappointing. We may need to find another way to get 
> reliable timing than setitimer.
> 
> I did change the first usleep(10) to usleep(1000) and that *may* help 
> with this problem by ensuring that we always interrupt the usleep 
> syscall consistently. I don't have my hp headphones (the set that's very 
> sensitive to timing) handy to test.

fwiw, I had to use the -n flag to a2play so it wouldn't use itimer at 
all. This flag tells a2play to just send the audio as fast as it can 
encode it.

Brad


-------------------------------------------------------
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


[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 3959 bytes --]

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

[Roberto]

Hi All/Victor,

I want to check the latestversion of SBC on mobile can somebody tell me how
we can get this version ? it is uopdated on the site ? which versioni is ?

Thanks Roberto

----- Original Message ----- 
From: "Victor Shcherbatyuk" <victor@win.tue.nl>
To: <bluez-devel@lists.sourceforge.net>
Sent: Monday, August 29, 2005 12:26 AM
Subject: Re: [Bluez-devel] sbc and fixed-point progress


> Brad,
>
> I've merged the fixed and floating point code added 32-bit fixed point
(not
> tested though), moved fixed point math to sbc_math.h. I've decided to use
> struct to keep hi and low parts of 64bit number, but now I'm stuck with
make
> it alighned onto 4 bytes boundary (I've tried __attribute__ ((alighned
(4),
> packed)) with the struct, but it does not help, apparently I'm missing
> something :) ), so currently everything is loaded byte-wise which is
> slow.... I'll try to ressolve the issue and then submit the changes...
>
> Regards,
>      Victor.
>
>
> ----- Original Message ----- 
> From: "Brad Midgley" <bmidgley@xmission.com>
> To: <bluez-devel@lists.sourceforge.net>
> Sent: Sunday, August 28, 2005 07:44
> Subject: Re: [Bluez-devel] sbc and fixed-point progress
>
>
> > Victor,
> >
> > Sorry... reapplied. I had thought this was one of my own fixed-point
> > tests. Thanks for keeping an eye on it.
> >
> > BTW, I started unrolling the decoder on paper and there's a ton of room
> > for optimization. I'll rewrite it in floating point to start with.
> >
> > Brad
> >
> >> For some reason a piece of code from my initial patch is missing for
cvs
> >> repository after the last updates... It is performance critical... I've
> >> attached the patch to bring it back. Or it was removed on purpose?
> >>
> >> Regards,
> >>      Victor.
> >>
> >> ----- Original Message ----- From: "Brad Midgley"
<bmidgley@xmission.com>
> >> To: <bluez-devel@lists.sourceforge.net>
> >> Sent: Friday, August 26, 2005 07:10
> >> Subject: Re: [Bluez-devel] sbc and fixed-point progress
> >>
> >>
> >>> Victor,
> >>>
> >>> How did you compute the floating point _anamatrix8[] and
_sbc_proto_8[]
> >>> in sbc_tables.h? (I am trying to improve the 4-subband code based on
> >>> your 8-subband float and fixed code.)
> >>>
> >>> BTW, I pulled out the testcode for fixed-point decoding now that
people
> >>> will compile with fixed point enabled and expect everything to work.
> >>>
> >>> thanks
> >>> Brad
> >>>
> >>> Victor Shcherbatyuk wrote:
> >>>
> >>>> Brad,
> >>>>
> >>>> I ran one more test and instead of -n flag for a2play I changed magic
> >>>> 87 to magic 50, CPU usage dropped >2 times to ~8% on ARM9@400Mhz and
> >>>> sound is still smooth. That's how it was tested in first place which
is
> >>>> close to 30 MIPS I guess...
> >>>>
> >>>> Regards,
> >>>>     Victor.
> >>>>
> >>>>
> >>>> -----Original Message-----
> >>>> From: bluez-devel-admin@lists.sourceforge.net on behalf of Victor
> >>>> Shcherbatyuk
> >>>> Sent: Tue 8/23/2005 5:00 PM
> >>>> To: bluez-devel@lists.sourceforge.net
> >>>> Subject: RE: [Bluez-devel] sbc and fixed-point progress
> >>>>  Hello Brad,
> >>>>
> >>>> I did some test runs on ARM9@400MHz, general fixed point encoder eats
> >>>> up ~40% of CPU time, while arm specific version  - ~20%. And in both
> >>>> cases it runs quite smooth. So the drops you had should have been
> >>>> caused by something else (unless you run some othe applications
> >>>> cuncurently).
> >>>>
> >>>>
> >>>> Victor.
> >>>>
> >>>>
> >>>> -----Original Message-----
> >>>> From: bluez-devel-admin@lists.sourceforge.net on behalf of Brad
Midgley
> >>>> Sent: Mon 8/22/2005 9:22 AM
> >>>> To: bluez-devel@lists.sourceforge.net
> >>>> Subject: Re: [Bluez-devel] sbc and fixed-point progress
> >>>>  Victor
> >>>>
> >>>>
> >>>>>> I do not have HW to test arm specific version real time, hope no
> >>>>>> suprises there, but I could have missed something when integrating
it
> >>>>>> into sbc code (it decodes well, but how fast, I will try only
monday
> >>>>>> evening).
> >>>>>
> >>>>>
> >>>>>
> >>>>> Ok, I'll load it on gumstix now and give it a try.
> >>>>
> >>>>
> >>>>
> >>>> This is almost perfect. On a 400mhz gumstix (pxa255), I'm able to
send
> >>>> a 5-minute audio stream with only about three breaks in the audio
> >>>> (about 5 seconds each).
> >>>>
> >>>> I think it will work flawlessly in 4 subbands or if we can shorten a
> >>>> few of the ops from 64 to 32 bit.
> >>>>
> >>>> I committed what's there and used __arm__ for the conditional asm
code.
> >>>>
> >>>>
> >>>>>> Using a2play needs to tweak 87 magic number, otherwise it drops
> >>>>>> samples?
> >>>>>
> >>>>>
> >>>>>
> >>>>> yes, this is disappointing. We may need to find another way to get
> >>>>> reliable timing than setitimer.
> >>>>>
> >>>>> I did change the first usleep(10) to usleep(1000) and that *may*
help
> >>>>> with this problem by ensuring that we always interrupt the usleep
> >>>>> syscall consistently. I don't have my hp headphones (the set that's
> >>>>> very sensitive to timing) handy to test.
> >>>>
> >>>>
> >>>>
> >>>> fwiw, I had to use the -n flag to a2play so it wouldn't use itimer at
> >>>> all. This flag tells a2play to just send the audio as fast as it can
> >>>> encode it.
> >>>>
> >>>> Brad
> >>>>
> >>>>
> >>>> -------------------------------------------------------
> >>>> 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
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

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

[Roberto]

okay fine I undestood but those CVS update are included ? either if are not
the latest  to be released as official ? if not can somebody send me the
version so I can check hwo is workiing on my side because until now I can
hear only noise and when Is start to ear the sound it will have many delay
maybe this can help me thansk Roberto

----- Original Message ----- 
From: "Brad Midgley" <bmidgley@xmission.com>
To: <bluez-devel@lists.sourceforge.net>
Sent: Monday, August 29, 2005 7:08 PM
Subject: Re: [Bluez-devel] sbc and fixed-point progress


> Roberto,
>
> If you follow the instructions at http://bluetooth-alsa.sf.net it will
> tell you how to use cvs to check out the current code including fixed
> point. (I will not be making a regular release until we nail down a few
> more things)
>
> Brad
>
> Roberto wrote:
> > Hi All/Victor,
> >
> > I want to check the latestversion of SBC on mobile can somebody tell me
how
> > we can get this version ? it is uopdated on the site ? which versioni is
?
> >
> > Thanks Roberto
> >
> > ----- Original Message ----- 
> > From: "Victor Shcherbatyuk" <victor@win.tue.nl>
> > To: <bluez-devel@lists.sourceforge.net>
> > Sent: Monday, August 29, 2005 12:26 AM
> > Subject: Re: [Bluez-devel] sbc and fixed-point progress
> >
> >
> >
> >>Brad,
> >>
> >>I've merged the fixed and floating point code added 32-bit fixed point
> >
> > (not
> >
> >>tested though), moved fixed point math to sbc_math.h. I've decided to
use
> >>struct to keep hi and low parts of 64bit number, but now I'm stuck with
> >
> > make
> >
> >>it alighned onto 4 bytes boundary (I've tried __attribute__ ((alighned
> >
> > (4),
> >
> >>packed)) with the struct, but it does not help, apparently I'm missing
> >>something :) ), so currently everything is loaded byte-wise which is
> >>slow.... I'll try to ressolve the issue and then submit the changes...
> >>
> >>Regards,
> >>     Victor.
> >>
> >>
> >>----- Original Message ----- 
> >>From: "Brad Midgley" <bmidgley@xmission.com>
> >>To: <bluez-devel@lists.sourceforge.net>
> >>Sent: Sunday, August 28, 2005 07:44
> >>Subject: Re: [Bluez-devel] sbc and fixed-point progress
> >>
> >>
> >>
> >>>Victor,
> >>>
> >>>Sorry... reapplied. I had thought this was one of my own fixed-point
> >>>tests. Thanks for keeping an eye on it.
> >>>
> >>>BTW, I started unrolling the decoder on paper and there's a ton of room
> >>>for optimization. I'll rewrite it in floating point to start with.
> >>>
> >>>Brad
> >>>
> >>>
> >>>>For some reason a piece of code from my initial patch is missing for
> >
> > cvs
> >
> >>>>repository after the last updates... It is performance critical...
I've
> >>>>attached the patch to bring it back. Or it was removed on purpose?
> >>>>
> >>>>Regards,
> >>>>     Victor.
> >>>>
> >>>>----- Original Message ----- From: "Brad Midgley"
> >
> > <bmidgley@xmission.com>
> >
> >>>>To: <bluez-devel@lists.sourceforge.net>
> >>>>Sent: Friday, August 26, 2005 07:10
> >>>>Subject: Re: [Bluez-devel] sbc and fixed-point progress
> >>>>
> >>>>
> >>>>
> >>>>>Victor,
> >>>>>
> >>>>>How did you compute the floating point _anamatrix8[] and
> >
> > _sbc_proto_8[]
> >
> >>>>>in sbc_tables.h? (I am trying to improve the 4-subband code based on
> >>>>>your 8-subband float and fixed code.)
> >>>>>
> >>>>>BTW, I pulled out the testcode for fixed-point decoding now that
> >
> > people
> >
> >>>>>will compile with fixed point enabled and expect everything to work.
> >>>>>
> >>>>>thanks
> >>>>>Brad
> >>>>>
> >>>>>Victor Shcherbatyuk wrote:
> >>>>>
> >>>>>
> >>>>>>Brad,
> >>>>>>
> >>>>>>I ran one more test and instead of -n flag for a2play I changed
magic
> >>>>>>87 to magic 50, CPU usage dropped >2 times to ~8% on ARM9@400Mhz and
> >>>>>>sound is still smooth. That's how it was tested in first place which
> >
> > is
> >
> >>>>>>close to 30 MIPS I guess...
> >>>>>>
> >>>>>>Regards,
> >>>>>>    Victor.
> >>>>>>
> >>>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: bluez-devel-admin@lists.sourceforge.net on behalf of Victor
> >>>>>>Shcherbatyuk
> >>>>>>Sent: Tue 8/23/2005 5:00 PM
> >>>>>>To: bluez-devel@lists.sourceforge.net
> >>>>>>Subject: RE: [Bluez-devel] sbc and fixed-point progress
> >>>>>> Hello Brad,
> >>>>>>
> >>>>>>I did some test runs on ARM9@400MHz, general fixed point encoder
eats
> >>>>>>up ~40% of CPU time, while arm specific version  - ~20%. And in both
> >>>>>>cases it runs quite smooth. So the drops you had should have been
> >>>>>>caused by something else (unless you run some othe applications
> >>>>>>cuncurently).
> >>>>>>
> >>>>>>
> >>>>>>Victor.
> >>>>>>
> >>>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: bluez-devel-admin@lists.sourceforge.net on behalf of Brad
> >
> > Midgley
> >
> >>>>>>Sent: Mon 8/22/2005 9:22 AM
> >>>>>>To: bluez-devel@lists.sourceforge.net
> >>>>>>Subject: Re: [Bluez-devel] sbc and fixed-point progress
> >>>>>> Victor
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>I do not have HW to test arm specific version real time, hope no
> >>>>>>>>suprises there, but I could have missed something when integrating
> >
> > it
> >
> >>>>>>>>into sbc code (it decodes well, but how fast, I will try only
> >
> > monday
> >
> >>>>>>>>evening).
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>Ok, I'll load it on gumstix now and give it a try.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>This is almost perfect. On a 400mhz gumstix (pxa255), I'm able to
> >
> > send
> >
> >>>>>>a 5-minute audio stream with only about three breaks in the audio
> >>>>>>(about 5 seconds each).
> >>>>>>
> >>>>>>I think it will work flawlessly in 4 subbands or if we can shorten a
> >>>>>>few of the ops from 64 to 32 bit.
> >>>>>>
> >>>>>>I committed what's there and used __arm__ for the conditional asm
> >
> > code.
> >
> >>>>>>
> >>>>>>>>Using a2play needs to tweak 87 magic number, otherwise it drops
> >>>>>>>>samples?
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>yes, this is disappointing. We may need to find another way to get
> >>>>>>>reliable timing than setitimer.
> >>>>>>>
> >>>>>>>I did change the first usleep(10) to usleep(1000) and that *may*
> >
> > help
> >
> >>>>>>>with this problem by ensuring that we always interrupt the usleep
> >>>>>>>syscall consistently. I don't have my hp headphones (the set that's
> >>>>>>>very sensitive to timing) handy to test.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>fwiw, I had to use the -n flag to a2play so it wouldn't use itimer
at
> >>>>>>all. This flag tells a2play to just send the audio as fast as it can
> >>>>>>encode it.
> >>>>>>
> >>>>>>Brad
> >>>>>>
> >>>>>>
> >>>>>>-------------------------------------------------------
> >>>>>>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
> > 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

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

[Victor Shcherbatyuk]

[-- Attachment #1: Type: text/plain, Size: 2866 bytes --]

Brad,

I ran one more test and instead of -n flag for a2play I changed magic 87 to magic 50, CPU usage dropped >2 times to ~8% on ARM9@400Mhz and sound is still smooth. That's how it was tested in first place which is close to 30 MIPS I guess...

Regards,
    Victor.


-----Original Message-----
From: bluez-devel-admin@lists.sourceforge.net on behalf of Victor Shcherbatyuk
Sent: Tue 8/23/2005 5:00 PM
To: bluez-devel@lists.sourceforge.net
Subject: RE: [Bluez-devel] sbc and fixed-point progress
 
Hello Brad,

I did some test runs on ARM9@400MHz, general fixed point encoder eats up ~40% of CPU time, while arm specific version  - ~20%. And in both cases it runs quite smooth. So the drops you had should have been caused by something else (unless you run some othe applications cuncurently).


Victor.


-----Original Message-----
From: bluez-devel-admin@lists.sourceforge.net on behalf of Brad Midgley
Sent: Mon 8/22/2005 9:22 AM
To: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] sbc and fixed-point progress
 
Victor

>> I do not have HW to test arm specific version real time, hope no 
>> suprises there, but I could have missed something when integrating it 
>> into sbc code (it decodes well, but how fast, I will try only monday 
>> evening).
> 
> 
> Ok, I'll load it on gumstix now and give it a try.

This is almost perfect. On a 400mhz gumstix (pxa255), I'm able to send a 
5-minute audio stream with only about three breaks in the audio (about 5 
seconds each).

I think it will work flawlessly in 4 subbands or if we can shorten a few 
of the ops from 64 to 32 bit.

I committed what's there and used __arm__ for the conditional asm code.

>> Using a2play needs to tweak 87 magic number, otherwise it drops samples?
> 
> 
> yes, this is disappointing. We may need to find another way to get 
> reliable timing than setitimer.
> 
> I did change the first usleep(10) to usleep(1000) and that *may* help 
> with this problem by ensuring that we always interrupt the usleep 
> syscall consistently. I don't have my hp headphones (the set that's very 
> sensitive to timing) handy to test.

fwiw, I had to use the -n flag to a2play so it wouldn't use itimer at 
all. This flag tells a2play to just send the audio as fast as it can 
encode it.

Brad


-------------------------------------------------------
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



[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 4227 bytes --]

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

[Brad Midgley]

Victor,

That's good news, glad to hear.

I thought itimer used the rtc behind the scenes but maybe we need to try 
latching into the rtc directly for our timing. It's insane to have to tweak.

Can you tell me if the sources you tested used the new usleep value? I 
committed a change to use 1000 in that first usleep call but you may not 
have updated and gotten it.

Brad

Victor Shcherbatyuk wrote:
> Brad,
> 
> I ran one more test and instead of -n flag for a2play I changed magic 87 to magic 50, CPU usage dropped >2 times to ~8% on ARM9@400Mhz and sound is still smooth. That's how it was tested in first place which is close to 30 MIPS I guess...
> 
> Regards,
>     Victor.


-------------------------------------------------------
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

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

[Victor Shcherbatyuk]

Brad,

Are you sure you've comitted the change? Cause all usleep's are still 10 and 
I've checked out just a minute ago.

Regards,
    Victor.

----- Original Message ----- 
From: "Brad Midgley" <bmidgley@xmission.com>
To: <bluez-devel@lists.sourceforge.net>
Sent: Wednesday, August 24, 2005 18:40
Subject: Re: [Bluez-devel] sbc and fixed-point progress


> Victor,
>
> That's good news, glad to hear.
>
> I thought itimer used the rtc behind the scenes but maybe we need to try 
> latching into the rtc directly for our timing. It's insane to have to 
> tweak.
>
> Can you tell me if the sources you tested used the new usleep value? I 
> committed a change to use 1000 in that first usleep call but you may not 
> have updated and gotten it.
>
> Brad
>
> Victor Shcherbatyuk wrote:
>> Brad,
>>
>> I ran one more test and instead of -n flag for a2play I changed magic 87 
>> to magic 50, CPU usage dropped >2 times to ~8% on ARM9@400Mhz and sound 
>> is still smooth. That's how it was tested in first place which is close 
>> to 30 MIPS I guess...
>>
>> Regards,
>>     Victor.
>
>
> -------------------------------------------------------
> 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

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

[Brad Midgley]

Victor,

How did you compute the floating point _anamatrix8[] and _sbc_proto_8[] 
in sbc_tables.h? (I am trying to improve the 4-subband code based on 
your 8-subband float and fixed code.)

BTW, I pulled out the testcode for fixed-point decoding now that people 
will compile with fixed point enabled and expect everything to work.

thanks
Brad

Victor Shcherbatyuk wrote:
> Brad,
> 
> I ran one more test and instead of -n flag for a2play I changed magic 87 to magic 50, CPU usage dropped >2 times to ~8% on ARM9@400Mhz and sound is still smooth. That's how it was tested in first place which is close to 30 MIPS I guess...
> 
> Regards,
>     Victor.
> 
> 
> -----Original Message-----
> From: bluez-devel-admin@lists.sourceforge.net on behalf of Victor Shcherbatyuk
> Sent: Tue 8/23/2005 5:00 PM
> To: bluez-devel@lists.sourceforge.net
> Subject: RE: [Bluez-devel] sbc and fixed-point progress
>  
> Hello Brad,
> 
> I did some test runs on ARM9@400MHz, general fixed point encoder eats up ~40% of CPU time, while arm specific version  - ~20%. And in both cases it runs quite smooth. So the drops you had should have been caused by something else (unless you run some othe applications cuncurently).
> 
> 
> Victor.
> 
> 
> -----Original Message-----
> From: bluez-devel-admin@lists.sourceforge.net on behalf of Brad Midgley
> Sent: Mon 8/22/2005 9:22 AM
> To: bluez-devel@lists.sourceforge.net
> Subject: Re: [Bluez-devel] sbc and fixed-point progress
>  
> Victor
> 
> 
>>>I do not have HW to test arm specific version real time, hope no 
>>>suprises there, but I could have missed something when integrating it 
>>>into sbc code (it decodes well, but how fast, I will try only monday 
>>>evening).
>>
>>
>>Ok, I'll load it on gumstix now and give it a try.
> 
> 
> This is almost perfect. On a 400mhz gumstix (pxa255), I'm able to send a 
> 5-minute audio stream with only about three breaks in the audio (about 5 
> seconds each).
> 
> I think it will work flawlessly in 4 subbands or if we can shorten a few 
> of the ops from 64 to 32 bit.
> 
> I committed what's there and used __arm__ for the conditional asm code.
> 
> 
>>>Using a2play needs to tweak 87 magic number, otherwise it drops samples?
>>
>>
>>yes, this is disappointing. We may need to find another way to get 
>>reliable timing than setitimer.
>>
>>I did change the first usleep(10) to usleep(1000) and that *may* help 
>>with this problem by ensuring that we always interrupt the usleep 
>>syscall consistently. I don't have my hp headphones (the set that's very 
>>sensitive to timing) handy to test.
> 
> 
> fwiw, I had to use the -n flag to a2play so it wouldn't use itimer at 
> all. This flag tells a2play to just send the audio as fast as it can 
> encode it.
> 
> Brad
> 
> 
> -------------------------------------------------------
> 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

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

[Victor Shcherbatyuk]

Brad,

The _anamatrix8[] and _sbc_proto_8[] are  extracted from anamatrix8[][]
and sbc_proto_8_80[].=20
Basically what I did is, made loop unrolling, then the rearanged
resulting code minimizing the number of multiplies, at this point I had
the code with the same structure as now, but using old matrices. After
this I've made single run of the filter printing out the matrices values
as the used, then put it in a array, eliminated elements with the same
value and modified the code to use the new array. So basically I did it
manually till some extent :)

Regards,
    Victor

P.S. There is a bug in general code of SUB64 (not much  influencing the
final result). I'll check in fix this weeken and also I did some
cleaning up of my code and added arm assembly for ADD64, SUB64. I still
plan to modify joint stereo code in sbc_pack_frame()  (as there are some
floating point ops still remain there) sbc_init() (and a2play) to accept
encoder parameters like nr. of subbands, bit pool and so on.

P.P.S. I'm also thinking to merge floating point and fixed point filter
code, so USE_FIXED will decide which macro to use floating or fixed
(general|arm). Btw, I also think it is quite easy to implement 32 bit
version this way.

-----Original Message-----
From: bluez-devel-admin@lists.sourceforge.net
[mailto:bluez-devel-admin@lists.sourceforge.net] On Behalf Of Brad
Midgley
Sent: Friday, August 26, 2005 7:11 AM
To: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] sbc and fixed-point progress

Victor,

How did you compute the floating point _anamatrix8[] and _sbc_proto_8[]
in sbc_tables.h? (I am trying to improve the 4-subband code based on
your 8-subband float and fixed code.)

BTW, I pulled out the testcode for fixed-point decoding now that people
will compile with fixed point enabled and expect everything to work.

thanks
Brad

Victor Shcherbatyuk wrote:
> Brad,
>=20
> I ran one more test and instead of -n flag for a2play I changed magic
87 to magic 50, CPU usage dropped >2 times to ~8% on ARM9@400Mhz and
sound is still smooth. That's how it was tested in first place which is
close to 30 MIPS I guess...
>=20
> Regards,
>     Victor.
>=20
>=20
> -----Original Message-----
> From: bluez-devel-admin@lists.sourceforge.net on behalf of Victor=20
> Shcherbatyuk
> Sent: Tue 8/23/2005 5:00 PM
> To: bluez-devel@lists.sourceforge.net
> Subject: RE: [Bluez-devel] sbc and fixed-point progress
> =20
> Hello Brad,
>=20
> I did some test runs on ARM9@400MHz, general fixed point encoder eats
up ~40% of CPU time, while arm specific version  - ~20%. And in both
cases it runs quite smooth. So the drops you had should have been caused
by something else (unless you run some othe applications cuncurently).
>=20
>=20
> Victor.
>=20
>=20
> -----Original Message-----
> From: bluez-devel-admin@lists.sourceforge.net on behalf of Brad=20
> Midgley
> Sent: Mon 8/22/2005 9:22 AM
> To: bluez-devel@lists.sourceforge.net
> Subject: Re: [Bluez-devel] sbc and fixed-point progress
> =20
> Victor
>=20
>=20
>>>I do not have HW to test arm specific version real time, hope no=20
>>>suprises there, but I could have missed something when integrating it

>>>into sbc code (it decodes well, but how fast, I will try only monday=20
>>>evening).
>>
>>
>>Ok, I'll load it on gumstix now and give it a try.
>=20
>=20
> This is almost perfect. On a 400mhz gumstix (pxa255), I'm able to send

> a 5-minute audio stream with only about three breaks in the audio=20
> (about 5 seconds each).
>=20
> I think it will work flawlessly in 4 subbands or if we can shorten a=20
> few of the ops from 64 to 32 bit.
>=20
> I committed what's there and used __arm__ for the conditional asm
code.
>=20
>=20
>>>Using a2play needs to tweak 87 magic number, otherwise it drops
samples?
>>
>>
>>yes, this is disappointing. We may need to find another way to get=20
>>reliable timing than setitimer.
>>
>>I did change the first usleep(10) to usleep(1000) and that *may* help=20
>>with this problem by ensuring that we always interrupt the usleep=20
>>syscall consistently. I don't have my hp headphones (the set that's=20
>>very sensitive to timing) handy to test.
>=20
>=20
> fwiw, I had to use the -n flag to a2play so it wouldn't use itimer at=20
> all. This flag tells a2play to just send the audio as fast as it can=20
> encode it.
>=20
> Brad
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO=20
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle=20
> Practices Agile & Plan-Driven Development * Managing Projects & Teams=20
> * Testing & QA Security * Process Improvement & Measurement *=20
> http://www.sqe.com/bsce5sf=20
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>=20
>=20


-------------------------------------------------------
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


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 immediatel=
y and delete or destroy this e-mail message and any attachment(s), withou=
t copying, saving, forwarding, disclosing or using its contents in any ot=
her way. TomTom N.V., TomTom International BV or any other company belong=
ing to the TomTom group of companies will not be liable for damage relati=
ng to the communication by e-mail of data, documents or any other informa=
tion.


-------------------------------------------------------
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

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

[Victor Shcherbatyuk]

Brad,

I've tested with usleep(1000), but it make no difference?=20

Regards,
     Victor.

-----Original Message-----
From: bluez-devel-admin@lists.sourceforge.net
[mailto:bluez-devel-admin@lists.sourceforge.net] On Behalf Of Brad
Midgley
Sent: Wednesday, August 24, 2005 18:41 PM
To: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] sbc and fixed-point progress

Victor,

That's good news, glad to hear.

I thought itimer used the rtc behind the scenes but maybe we need to try
latching into the rtc directly for our timing. It's insane to have to
tweak.

Can you tell me if the sources you tested used the new usleep value? I
committed a change to use 1000 in that first usleep call but you may not
have updated and gotten it.

Brad

Victor Shcherbatyuk wrote:
> Brad,
>=20
> I ran one more test and instead of -n flag for a2play I changed magic
87 to magic 50, CPU usage dropped >2 times to ~8% on ARM9@400Mhz and
sound is still smooth. That's how it was tested in first place which is
close to 30 MIPS I guess...
>=20
> Regards,
>     Victor.


-------------------------------------------------------
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


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 immediatel=
y and delete or destroy this e-mail message and any attachment(s), withou=
t copying, saving, forwarding, disclosing or using its contents in any ot=
her way. TomTom N.V., TomTom International BV or any other company belong=
ing to the TomTom group of companies will not be liable for damage relati=
ng to the communication by e-mail of data, documents or any other informa=
tion.


-------------------------------------------------------
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

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

[Brad Midgley]

Victor

> The _anamatrix8[] and _sbc_proto_8[] are  extracted from anamatrix8[][]
> and sbc_proto_8_80[]. 
> Basically what I did is, made loop unrolling, then the rearanged
> resulting code minimizing the number of multiplies

wow. you the man as they say.

FYI I stubbed in the fixed-point 4 subband stuff for now but I'd 
eventually like to see it in there. Curently it may not behave right 
when you build with USE_FIXED and then encode with 4 subbands (it tries 
to use floating point)

I don't know if you've used 4 subbands much, but it sounds quite 
respectable and it would allow us to scale down to some of the 
smallest/slowest embedded processors out there (memory permitting).

> P.S. There is a bug in general code of SUB64 (not much  influencing the
> final result). I'll check in fix this weeken and also I did some
> cleaning up of my code and added arm assembly for ADD64, SUB64. I still
> plan to modify joint stereo code in sbc_pack_frame()  (as there are some
> floating point ops still remain there) sbc_init() (and a2play) to accept
> encoder parameters like nr. of subbands, bit pool and so on.

you probably saw that a2play has some rough options for encoder params, 
jut the -t (thrifty) flag.

> P.P.S. I'm also thinking to merge floating point and fixed point filter
> code, so USE_FIXED will decide which macro to use floating or fixed
> (general|arm). Btw, I also think it is quite easy to implement 32 bit
> version this way.

nice

Brad


-------------------------------------------------------
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

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

[Victor Shcherbatyuk]

[-- Attachment #1: Type: text/plain, Size: 4393 bytes --]

Brad,

For some reason a piece of code from my initial patch is missing for cvs 
repository after the last updates... It is performance critical... I've 
attached the patch to bring it back. Or it was removed on purpose?

Regards,
      Victor.

----- Original Message ----- 
From: "Brad Midgley" <bmidgley@xmission.com>
To: <bluez-devel@lists.sourceforge.net>
Sent: Friday, August 26, 2005 07:10
Subject: Re: [Bluez-devel] sbc and fixed-point progress


> Victor,
>
> How did you compute the floating point _anamatrix8[] and _sbc_proto_8[] in 
> sbc_tables.h? (I am trying to improve the 4-subband code based on your 
> 8-subband float and fixed code.)
>
> BTW, I pulled out the testcode for fixed-point decoding now that people 
> will compile with fixed point enabled and expect everything to work.
>
> thanks
> Brad
>
> Victor Shcherbatyuk wrote:
>> Brad,
>>
>> I ran one more test and instead of -n flag for a2play I changed magic 87 
>> to magic 50, CPU usage dropped >2 times to ~8% on ARM9@400Mhz and sound 
>> is still smooth. That's how it was tested in first place which is close 
>> to 30 MIPS I guess...
>>
>> Regards,
>>     Victor.
>>
>>
>> -----Original Message-----
>> From: bluez-devel-admin@lists.sourceforge.net on behalf of Victor 
>> Shcherbatyuk
>> Sent: Tue 8/23/2005 5:00 PM
>> To: bluez-devel@lists.sourceforge.net
>> Subject: RE: [Bluez-devel] sbc and fixed-point progress
>>  Hello Brad,
>>
>> I did some test runs on ARM9@400MHz, general fixed point encoder eats up 
>> ~40% of CPU time, while arm specific version  - ~20%. And in both cases 
>> it runs quite smooth. So the drops you had should have been caused by 
>> something else (unless you run some othe applications cuncurently).
>>
>>
>> Victor.
>>
>>
>> -----Original Message-----
>> From: bluez-devel-admin@lists.sourceforge.net on behalf of Brad Midgley
>> Sent: Mon 8/22/2005 9:22 AM
>> To: bluez-devel@lists.sourceforge.net
>> Subject: Re: [Bluez-devel] sbc and fixed-point progress
>>  Victor
>>
>>
>>>>I do not have HW to test arm specific version real time, hope no 
>>>>suprises there, but I could have missed something when integrating it 
>>>>into sbc code (it decodes well, but how fast, I will try only monday 
>>>>evening).
>>>
>>>
>>>Ok, I'll load it on gumstix now and give it a try.
>>
>>
>> This is almost perfect. On a 400mhz gumstix (pxa255), I'm able to send a 
>> 5-minute audio stream with only about three breaks in the audio (about 5 
>> seconds each).
>>
>> I think it will work flawlessly in 4 subbands or if we can shorten a few 
>> of the ops from 64 to 32 bit.
>>
>> I committed what's there and used __arm__ for the conditional asm code.
>>
>>
>>>>Using a2play needs to tweak 87 magic number, otherwise it drops samples?
>>>
>>>
>>>yes, this is disappointing. We may need to find another way to get 
>>>reliable timing than setitimer.
>>>
>>>I did change the first usleep(10) to usleep(1000) and that *may* help 
>>>with this problem by ensuring that we always interrupt the usleep syscall 
>>>consistently. I don't have my hp headphones (the set that's very 
>>>sensitive to timing) handy to test.
>>
>>
>> fwiw, I had to use the -n flag to a2play so it wouldn't use itimer at 
>> all. This flag tells a2play to just send the audio as fast as it can 
>> encode it.
>>
>> Brad
>>
>>
>> -------------------------------------------------------
>> 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 

[-- Attachment #2: sbc.patch --]
[-- Type: application/octet-stream, Size: 888 bytes --]

? sbc.patch
Index: sbc/sbc.c
===================================================================
RCS file: /cvsroot/bluetooth-alsa/btsco/sbc/sbc.c,v
retrieving revision 1.52
diff -u -r1.52 sbc.c
--- sbc/sbc.c	27 Aug 2005 02:17:54 -0000	1.52
+++ sbc/sbc.c	27 Aug 2005 22:47:40 -0000
@@ -1432,9 +1432,15 @@
 		for (ch = 0; ch < frame->channels; ch++) {
 			for (sb = 0; sb < frame->subbands; sb++) {
 				if (levels[ch][sb] > 0) {
+#ifdef USE_FIXED
+					frame->audio_sample[blk][ch][sb] =
+						(u_int16_t) ((((frame->sb_sample_f[blk][ch][sb]*levels[ch][sb]) >> (frame->scale_factor[ch][sb] + 1)) +
+						levels[ch][sb]) >> 1);
+#else
 					frame->audio_sample[blk][ch][sb] =
 						(u_int16_t) (((frame->sb_sample[blk][ch][sb] / scalefactor[ch][sb] +
 						1.0) * levels[ch][sb]) / 2.0);
+#endif
 				} else {
 					frame->audio_sample[blk][ch][sb] = 0;
 				}

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

[Brad Midgley]

Victor,

Sorry... reapplied. I had thought this was one of my own fixed-point 
tests. Thanks for keeping an eye on it.

BTW, I started unrolling the decoder on paper and there's a ton of room 
for optimization. I'll rewrite it in floating point to start with.

Brad

> For some reason a piece of code from my initial patch is missing for cvs 
> repository after the last updates... It is performance critical... I've 
> attached the patch to bring it back. Or it was removed on purpose?
> 
> Regards,
>      Victor.
> 
> ----- Original Message ----- From: "Brad Midgley" <bmidgley@xmission.com>
> To: <bluez-devel@lists.sourceforge.net>
> Sent: Friday, August 26, 2005 07:10
> Subject: Re: [Bluez-devel] sbc and fixed-point progress
> 
> 
>> Victor,
>>
>> How did you compute the floating point _anamatrix8[] and 
>> _sbc_proto_8[] in sbc_tables.h? (I am trying to improve the 4-subband 
>> code based on your 8-subband float and fixed code.)
>>
>> BTW, I pulled out the testcode for fixed-point decoding now that 
>> people will compile with fixed point enabled and expect everything to 
>> work.
>>
>> thanks
>> Brad
>>
>> Victor Shcherbatyuk wrote:
>>
>>> Brad,
>>>
>>> I ran one more test and instead of -n flag for a2play I changed magic 
>>> 87 to magic 50, CPU usage dropped >2 times to ~8% on ARM9@400Mhz and 
>>> sound is still smooth. That's how it was tested in first place which 
>>> is close to 30 MIPS I guess...
>>>
>>> Regards,
>>>     Victor.
>>>
>>>
>>> -----Original Message-----
>>> From: bluez-devel-admin@lists.sourceforge.net on behalf of Victor 
>>> Shcherbatyuk
>>> Sent: Tue 8/23/2005 5:00 PM
>>> To: bluez-devel@lists.sourceforge.net
>>> Subject: RE: [Bluez-devel] sbc and fixed-point progress
>>>  Hello Brad,
>>>
>>> I did some test runs on ARM9@400MHz, general fixed point encoder eats 
>>> up ~40% of CPU time, while arm specific version  - ~20%. And in both 
>>> cases it runs quite smooth. So the drops you had should have been 
>>> caused by something else (unless you run some othe applications 
>>> cuncurently).
>>>
>>>
>>> Victor.
>>>
>>>
>>> -----Original Message-----
>>> From: bluez-devel-admin@lists.sourceforge.net on behalf of Brad Midgley
>>> Sent: Mon 8/22/2005 9:22 AM
>>> To: bluez-devel@lists.sourceforge.net
>>> Subject: Re: [Bluez-devel] sbc and fixed-point progress
>>>  Victor
>>>
>>>
>>>>> I do not have HW to test arm specific version real time, hope no 
>>>>> suprises there, but I could have missed something when integrating 
>>>>> it into sbc code (it decodes well, but how fast, I will try only 
>>>>> monday evening).
>>>>
>>>>
>>>>
>>>> Ok, I'll load it on gumstix now and give it a try.
>>>
>>>
>>>
>>> This is almost perfect. On a 400mhz gumstix (pxa255), I'm able to 
>>> send a 5-minute audio stream with only about three breaks in the 
>>> audio (about 5 seconds each).
>>>
>>> I think it will work flawlessly in 4 subbands or if we can shorten a 
>>> few of the ops from 64 to 32 bit.
>>>
>>> I committed what's there and used __arm__ for the conditional asm code.
>>>
>>>
>>>>> Using a2play needs to tweak 87 magic number, otherwise it drops 
>>>>> samples?
>>>>
>>>>
>>>>
>>>> yes, this is disappointing. We may need to find another way to get 
>>>> reliable timing than setitimer.
>>>>
>>>> I did change the first usleep(10) to usleep(1000) and that *may* 
>>>> help with this problem by ensuring that we always interrupt the 
>>>> usleep syscall consistently. I don't have my hp headphones (the set 
>>>> that's very sensitive to timing) handy to test.
>>>
>>>
>>>
>>> fwiw, I had to use the -n flag to a2play so it wouldn't use itimer at 
>>> all. This flag tells a2play to just send the audio as fast as it can 
>>> encode it.
>>>
>>> Brad
>>>
>>>
>>> -------------------------------------------------------
>>> 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

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

[Victor Shcherbatyuk]

Brad,

I've merged the fixed and floating point code added 32-bit fixed point (not 
tested though), moved fixed point math to sbc_math.h. I've decided to use 
struct to keep hi and low parts of 64bit number, but now I'm stuck with make 
it alighned onto 4 bytes boundary (I've tried __attribute__ ((alighned (4), 
packed)) with the struct, but it does not help, apparently I'm missing 
something :) ), so currently everything is loaded byte-wise which is 
slow.... I'll try to ressolve the issue and then submit the changes...

Regards,
     Victor.


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


> Victor,
>
> Sorry... reapplied. I had thought this was one of my own fixed-point 
> tests. Thanks for keeping an eye on it.
>
> BTW, I started unrolling the decoder on paper and there's a ton of room 
> for optimization. I'll rewrite it in floating point to start with.
>
> Brad
>
>> For some reason a piece of code from my initial patch is missing for cvs 
>> repository after the last updates... It is performance critical... I've 
>> attached the patch to bring it back. Or it was removed on purpose?
>>
>> Regards,
>>      Victor.
>>
>> ----- Original Message ----- From: "Brad Midgley" <bmidgley@xmission.com>
>> To: <bluez-devel@lists.sourceforge.net>
>> Sent: Friday, August 26, 2005 07:10
>> Subject: Re: [Bluez-devel] sbc and fixed-point progress
>>
>>
>>> Victor,
>>>
>>> How did you compute the floating point _anamatrix8[] and _sbc_proto_8[] 
>>> in sbc_tables.h? (I am trying to improve the 4-subband code based on 
>>> your 8-subband float and fixed code.)
>>>
>>> BTW, I pulled out the testcode for fixed-point decoding now that people 
>>> will compile with fixed point enabled and expect everything to work.
>>>
>>> thanks
>>> Brad
>>>
>>> Victor Shcherbatyuk wrote:
>>>
>>>> Brad,
>>>>
>>>> I ran one more test and instead of -n flag for a2play I changed magic 
>>>> 87 to magic 50, CPU usage dropped >2 times to ~8% on ARM9@400Mhz and 
>>>> sound is still smooth. That's how it was tested in first place which is 
>>>> close to 30 MIPS I guess...
>>>>
>>>> Regards,
>>>>     Victor.
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: bluez-devel-admin@lists.sourceforge.net on behalf of Victor 
>>>> Shcherbatyuk
>>>> Sent: Tue 8/23/2005 5:00 PM
>>>> To: bluez-devel@lists.sourceforge.net
>>>> Subject: RE: [Bluez-devel] sbc and fixed-point progress
>>>>  Hello Brad,
>>>>
>>>> I did some test runs on ARM9@400MHz, general fixed point encoder eats 
>>>> up ~40% of CPU time, while arm specific version  - ~20%. And in both 
>>>> cases it runs quite smooth. So the drops you had should have been 
>>>> caused by something else (unless you run some othe applications 
>>>> cuncurently).
>>>>
>>>>
>>>> Victor.
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: bluez-devel-admin@lists.sourceforge.net on behalf of Brad Midgley
>>>> Sent: Mon 8/22/2005 9:22 AM
>>>> To: bluez-devel@lists.sourceforge.net
>>>> Subject: Re: [Bluez-devel] sbc and fixed-point progress
>>>>  Victor
>>>>
>>>>
>>>>>> I do not have HW to test arm specific version real time, hope no 
>>>>>> suprises there, but I could have missed something when integrating it 
>>>>>> into sbc code (it decodes well, but how fast, I will try only monday 
>>>>>> evening).
>>>>>
>>>>>
>>>>>
>>>>> Ok, I'll load it on gumstix now and give it a try.
>>>>
>>>>
>>>>
>>>> This is almost perfect. On a 400mhz gumstix (pxa255), I'm able to send 
>>>> a 5-minute audio stream with only about three breaks in the audio 
>>>> (about 5 seconds each).
>>>>
>>>> I think it will work flawlessly in 4 subbands or if we can shorten a 
>>>> few of the ops from 64 to 32 bit.
>>>>
>>>> I committed what's there and used __arm__ for the conditional asm code.
>>>>
>>>>
>>>>>> Using a2play needs to tweak 87 magic number, otherwise it drops 
>>>>>> samples?
>>>>>
>>>>>
>>>>>
>>>>> yes, this is disappointing. We may need to find another way to get 
>>>>> reliable timing than setitimer.
>>>>>
>>>>> I did change the first usleep(10) to usleep(1000) and that *may* help 
>>>>> with this problem by ensuring that we always interrupt the usleep 
>>>>> syscall consistently. I don't have my hp headphones (the set that's 
>>>>> very sensitive to timing) handy to test.
>>>>
>>>>
>>>>
>>>> fwiw, I had to use the -n flag to a2play so it wouldn't use itimer at 
>>>> all. This flag tells a2play to just send the audio as fast as it can 
>>>> encode it.
>>>>
>>>> Brad
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> 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

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

[Brad Midgley]

Roberto,

If you follow the instructions at http://bluetooth-alsa.sf.net it will 
tell you how to use cvs to check out the current code including fixed 
point. (I will not be making a regular release until we nail down a few 
more things)

Brad

Roberto wrote:
> Hi All/Victor,
> 
> I want to check the latestversion of SBC on mobile can somebody tell me how
> we can get this version ? it is uopdated on the site ? which versioni is ?
> 
> Thanks Roberto
> 
> ----- Original Message ----- 
> From: "Victor Shcherbatyuk" <victor@win.tue.nl>
> To: <bluez-devel@lists.sourceforge.net>
> Sent: Monday, August 29, 2005 12:26 AM
> Subject: Re: [Bluez-devel] sbc and fixed-point progress
> 
> 
> 
>>Brad,
>>
>>I've merged the fixed and floating point code added 32-bit fixed point
> 
> (not
> 
>>tested though), moved fixed point math to sbc_math.h. I've decided to use
>>struct to keep hi and low parts of 64bit number, but now I'm stuck with
> 
> make
> 
>>it alighned onto 4 bytes boundary (I've tried __attribute__ ((alighned
> 
> (4),
> 
>>packed)) with the struct, but it does not help, apparently I'm missing
>>something :) ), so currently everything is loaded byte-wise which is
>>slow.... I'll try to ressolve the issue and then submit the changes...
>>
>>Regards,
>>     Victor.
>>
>>
>>----- Original Message ----- 
>>From: "Brad Midgley" <bmidgley@xmission.com>
>>To: <bluez-devel@lists.sourceforge.net>
>>Sent: Sunday, August 28, 2005 07:44
>>Subject: Re: [Bluez-devel] sbc and fixed-point progress
>>
>>
>>
>>>Victor,
>>>
>>>Sorry... reapplied. I had thought this was one of my own fixed-point
>>>tests. Thanks for keeping an eye on it.
>>>
>>>BTW, I started unrolling the decoder on paper and there's a ton of room
>>>for optimization. I'll rewrite it in floating point to start with.
>>>
>>>Brad
>>>
>>>
>>>>For some reason a piece of code from my initial patch is missing for
> 
> cvs
> 
>>>>repository after the last updates... It is performance critical... I've
>>>>attached the patch to bring it back. Or it was removed on purpose?
>>>>
>>>>Regards,
>>>>     Victor.
>>>>
>>>>----- Original Message ----- From: "Brad Midgley"
> 
> <bmidgley@xmission.com>
> 
>>>>To: <bluez-devel@lists.sourceforge.net>
>>>>Sent: Friday, August 26, 2005 07:10
>>>>Subject: Re: [Bluez-devel] sbc and fixed-point progress
>>>>
>>>>
>>>>
>>>>>Victor,
>>>>>
>>>>>How did you compute the floating point _anamatrix8[] and
> 
> _sbc_proto_8[]
> 
>>>>>in sbc_tables.h? (I am trying to improve the 4-subband code based on
>>>>>your 8-subband float and fixed code.)
>>>>>
>>>>>BTW, I pulled out the testcode for fixed-point decoding now that
> 
> people
> 
>>>>>will compile with fixed point enabled and expect everything to work.
>>>>>
>>>>>thanks
>>>>>Brad
>>>>>
>>>>>Victor Shcherbatyuk wrote:
>>>>>
>>>>>
>>>>>>Brad,
>>>>>>
>>>>>>I ran one more test and instead of -n flag for a2play I changed magic
>>>>>>87 to magic 50, CPU usage dropped >2 times to ~8% on ARM9@400Mhz and
>>>>>>sound is still smooth. That's how it was tested in first place which
> 
> is
> 
>>>>>>close to 30 MIPS I guess...
>>>>>>
>>>>>>Regards,
>>>>>>    Victor.
>>>>>>
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: bluez-devel-admin@lists.sourceforge.net on behalf of Victor
>>>>>>Shcherbatyuk
>>>>>>Sent: Tue 8/23/2005 5:00 PM
>>>>>>To: bluez-devel@lists.sourceforge.net
>>>>>>Subject: RE: [Bluez-devel] sbc and fixed-point progress
>>>>>> Hello Brad,
>>>>>>
>>>>>>I did some test runs on ARM9@400MHz, general fixed point encoder eats
>>>>>>up ~40% of CPU time, while arm specific version  - ~20%. And in both
>>>>>>cases it runs quite smooth. So the drops you had should have been
>>>>>>caused by something else (unless you run some othe applications
>>>>>>cuncurently).
>>>>>>
>>>>>>
>>>>>>Victor.
>>>>>>
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: bluez-devel-admin@lists.sourceforge.net on behalf of Brad
> 
> Midgley
> 
>>>>>>Sent: Mon 8/22/2005 9:22 AM
>>>>>>To: bluez-devel@lists.sourceforge.net
>>>>>>Subject: Re: [Bluez-devel] sbc and fixed-point progress
>>>>>> Victor
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>I do not have HW to test arm specific version real time, hope no
>>>>>>>>suprises there, but I could have missed something when integrating
> 
> it
> 
>>>>>>>>into sbc code (it decodes well, but how fast, I will try only
> 
> monday
> 
>>>>>>>>evening).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>Ok, I'll load it on gumstix now and give it a try.
>>>>>>
>>>>>>
>>>>>>
>>>>>>This is almost perfect. On a 400mhz gumstix (pxa255), I'm able to
> 
> send
> 
>>>>>>a 5-minute audio stream with only about three breaks in the audio
>>>>>>(about 5 seconds each).
>>>>>>
>>>>>>I think it will work flawlessly in 4 subbands or if we can shorten a
>>>>>>few of the ops from 64 to 32 bit.
>>>>>>
>>>>>>I committed what's there and used __arm__ for the conditional asm
> 
> code.
> 
>>>>>>
>>>>>>>>Using a2play needs to tweak 87 magic number, otherwise it drops
>>>>>>>>samples?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>yes, this is disappointing. We may need to find another way to get
>>>>>>>reliable timing than setitimer.
>>>>>>>
>>>>>>>I did change the first usleep(10) to usleep(1000) and that *may*
> 
> help
> 
>>>>>>>with this problem by ensuring that we always interrupt the usleep
>>>>>>>syscall consistently. I don't have my hp headphones (the set that's
>>>>>>>very sensitive to timing) handy to test.
>>>>>>
>>>>>>
>>>>>>
>>>>>>fwiw, I had to use the -n flag to a2play so it wouldn't use itimer at
>>>>>>all. This flag tells a2play to just send the audio as fast as it can
>>>>>>encode it.
>>>>>>
>>>>>>Brad
>>>>>>
>>>>>>
>>>>>>-------------------------------------------------------
>>>>>>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
> 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

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

[Brad Midgley]

Roberto

A cvs checkout or update as of today contains the fixed-point encoder 
for 8 subbands (highest quality option) and a stab at using the 
real-time clock for transmission as an option. Victor is discussing some 
more changes but he hasn't submitted anything yet.

I am planning to do a 0.5 release but I'd like to wait until 4 subbands 
are covered. I think 4 subbands might not even work right now when 
compiled for fixed point.

Tell us more about what devices you're using and the command-line you 
used to configure, build and run a2play etc. We have only had recent 
problems with noise if the input to a2play isn't in the right format. 
Don't use the -t option to a2play because it will give you the 4 subband 
encoder.

Brad

Roberto wrote:
> okay fine I undestood but those CVS update are included ? either if are not
> the latest  to be released as official ? if not can somebody send me the
> version so I can check hwo is workiing on my side because until now I can
> hear only noise and when Is start to ear the sound it will have many delay
> maybe this can help me thansk Roberto
> 
> ----- Original Message ----- 
> From: "Brad Midgley" <bmidgley@xmission.com>
> To: <bluez-devel@lists.sourceforge.net>
> Sent: Monday, August 29, 2005 7:08 PM
> Subject: Re: [Bluez-devel] sbc and fixed-point progress
> 
> 
> 
>>Roberto,
>>
>>If you follow the instructions at http://bluetooth-alsa.sf.net it will
>>tell you how to use cvs to check out the current code including fixed
>>point. (I will not be making a regular release until we nail down a few
>>more things)
>>
>>Brad
>>
>>Roberto wrote:
>>
>>>Hi All/Victor,
>>>
>>>I want to check the latestversion of SBC on mobile can somebody tell me
> 
> how
> 
>>>we can get this version ? it is uopdated on the site ? which versioni is
> 
> ?
> 
>>>Thanks Roberto
>>>
>>>----- Original Message ----- 
>>>From: "Victor Shcherbatyuk" <victor@win.tue.nl>
>>>To: <bluez-devel@lists.sourceforge.net>
>>>Sent: Monday, August 29, 2005 12:26 AM
>>>Subject: Re: [Bluez-devel] sbc and fixed-point progress
>>>
>>>
>>>
>>>
>>>>Brad,
>>>>
>>>>I've merged the fixed and floating point code added 32-bit fixed point
>>>
>>>(not
>>>
>>>
>>>>tested though), moved fixed point math to sbc_math.h. I've decided to
> 
> use
> 
>>>>struct to keep hi and low parts of 64bit number, but now I'm stuck with
>>>
>>>make
>>>
>>>
>>>>it alighned onto 4 bytes boundary (I've tried __attribute__ ((alighned
>>>
>>>(4),
>>>
>>>
>>>>packed)) with the struct, but it does not help, apparently I'm missing
>>>>something :) ), so currently everything is loaded byte-wise which is
>>>>slow.... I'll try to ressolve the issue and then submit the changes...
>>>>
>>>>Regards,
>>>>    Victor.
>>>>
>>>>
>>>>----- Original Message ----- 
>>>>From: "Brad Midgley" <bmidgley@xmission.com>
>>>>To: <bluez-devel@lists.sourceforge.net>
>>>>Sent: Sunday, August 28, 2005 07:44
>>>>Subject: Re: [Bluez-devel] sbc and fixed-point progress
>>>>
>>>>
>>>>
>>>>
>>>>>Victor,
>>>>>
>>>>>Sorry... reapplied. I had thought this was one of my own fixed-point
>>>>>tests. Thanks for keeping an eye on it.
>>>>>
>>>>>BTW, I started unrolling the decoder on paper and there's a ton of room
>>>>>for optimization. I'll rewrite it in floating point to start with.
>>>>>
>>>>>Brad
>>>>>
>>>>>
>>>>>
>>>>>>For some reason a piece of code from my initial patch is missing for
>>>
>>>cvs
>>>
>>>
>>>>>>repository after the last updates... It is performance critical...
> 
> I've
> 
>>>>>>attached the patch to bring it back. Or it was removed on purpose?
>>>>>>
>>>>>>Regards,
>>>>>>    Victor.
>>>>>>
>>>>>>----- Original Message ----- From: "Brad Midgley"
>>>
>>><bmidgley@xmission.com>
>>>
>>>>>>To: <bluez-devel@lists.sourceforge.net>
>>>>>>Sent: Friday, August 26, 2005 07:10
>>>>>>Subject: Re: [Bluez-devel] sbc and fixed-point progress
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Victor,
>>>>>>>
>>>>>>>How did you compute the floating point _anamatrix8[] and
>>>
>>>_sbc_proto_8[]
>>>
>>>
>>>>>>>in sbc_tables.h? (I am trying to improve the 4-subband code based on
>>>>>>>your 8-subband float and fixed code.)
>>>>>>>
>>>>>>>BTW, I pulled out the testcode for fixed-point decoding now that
>>>
>>>people
>>>
>>>
>>>>>>>will compile with fixed point enabled and expect everything to work.
>>>>>>>
>>>>>>>thanks
>>>>>>>Brad
>>>>>>>
>>>>>>>Victor Shcherbatyuk wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Brad,
>>>>>>>>
>>>>>>>>I ran one more test and instead of -n flag for a2play I changed
> 
> magic
> 
>>>>>>>>87 to magic 50, CPU usage dropped >2 times to ~8% on ARM9@400Mhz and
>>>>>>>>sound is still smooth. That's how it was tested in first place which
>>>
>>>is
>>>
>>>
>>>>>>>>close to 30 MIPS I guess...
>>>>>>>>
>>>>>>>>Regards,
>>>>>>>>   Victor.
>>>>>>>>
>>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: bluez-devel-admin@lists.sourceforge.net on behalf of Victor
>>>>>>>>Shcherbatyuk
>>>>>>>>Sent: Tue 8/23/2005 5:00 PM
>>>>>>>>To: bluez-devel@lists.sourceforge.net
>>>>>>>>Subject: RE: [Bluez-devel] sbc and fixed-point progress
>>>>>>>>Hello Brad,
>>>>>>>>
>>>>>>>>I did some test runs on ARM9@400MHz, general fixed point encoder
> 
> eats
> 
>>>>>>>>up ~40% of CPU time, while arm specific version  - ~20%. And in both
>>>>>>>>cases it runs quite smooth. So the drops you had should have been
>>>>>>>>caused by something else (unless you run some othe applications
>>>>>>>>cuncurently).
>>>>>>>>
>>>>>>>>
>>>>>>>>Victor.
>>>>>>>>
>>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: bluez-devel-admin@lists.sourceforge.net on behalf of Brad
>>>
>>>Midgley
>>>
>>>
>>>>>>>>Sent: Mon 8/22/2005 9:22 AM
>>>>>>>>To: bluez-devel@lists.sourceforge.net
>>>>>>>>Subject: Re: [Bluez-devel] sbc and fixed-point progress
>>>>>>>>Victor
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>I do not have HW to test arm specific version real time, hope no
>>>>>>>>>>suprises there, but I could have missed something when integrating
>>>
>>>it
>>>
>>>
>>>>>>>>>>into sbc code (it decodes well, but how fast, I will try only
>>>
>>>monday
>>>
>>>
>>>>>>>>>>evening).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Ok, I'll load it on gumstix now and give it a try.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>This is almost perfect. On a 400mhz gumstix (pxa255), I'm able to
>>>
>>>send
>>>
>>>
>>>>>>>>a 5-minute audio stream with only about three breaks in the audio
>>>>>>>>(about 5 seconds each).
>>>>>>>>
>>>>>>>>I think it will work flawlessly in 4 subbands or if we can shorten a
>>>>>>>>few of the ops from 64 to 32 bit.
>>>>>>>>
>>>>>>>>I committed what's there and used __arm__ for the conditional asm
>>>
>>>code.
>>>
>>>
>>>>>>>>>>Using a2play needs to tweak 87 magic number, otherwise it drops
>>>>>>>>>>samples?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>yes, this is disappointing. We may need to find another way to get
>>>>>>>>>reliable timing than setitimer.
>>>>>>>>>
>>>>>>>>>I did change the first usleep(10) to usleep(1000) and that *may*
>>>
>>>help
>>>
>>>
>>>>>>>>>with this problem by ensuring that we always interrupt the usleep
>>>>>>>>>syscall consistently. I don't have my hp headphones (the set that's
>>>>>>>>>very sensitive to timing) handy to test.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>fwiw, I had to use the -n flag to a2play so it wouldn't use itimer
> 
> at
> 
>>>>>>>>all. This flag tells a2play to just send the audio as fast as it can
>>>>>>>>encode it.
>>>>>>>>
>>>>>>>>Brad
>>>>>>>>
>>>>>>>>
>>>>>>>>-------------------------------------------------------
>>>>>>>>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
> 
>>>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

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

[Roberto]

we use our stack for symbian we need only the SBC encoding sometime if the
headset don't support native mp3 (MPEG1,2) and use only SBC so we have to
decode MP3 and re-encode SBC again this is one of the biggest problem
especially because mprocessor of mobiel phone are quite slow :)  will keep
you updated ... thansk ROberto

----- Original Message ----- 
From: "Brad Midgley" <bmidgley@xmission.com>
To: <bluez-devel@lists.sourceforge.net>
Sent: Monday, August 29, 2005 10:18 PM
Subject: Re: [Bluez-devel] sbc and fixed-point progress


> Roberto
>
> A cvs checkout or update as of today contains the fixed-point encoder
> for 8 subbands (highest quality option) and a stab at using the
> real-time clock for transmission as an option. Victor is discussing some
> more changes but he hasn't submitted anything yet.
>
> I am planning to do a 0.5 release but I'd like to wait until 4 subbands
> are covered. I think 4 subbands might not even work right now when
> compiled for fixed point.
>
> Tell us more about what devices you're using and the command-line you
> used to configure, build and run a2play etc. We have only had recent
> problems with noise if the input to a2play isn't in the right format.
> Don't use the -t option to a2play because it will give you the 4 subband
> encoder.
>
> Brad
>
> Roberto wrote:
> > okay fine I undestood but those CVS update are included ? either if are
not
> > the latest  to be released as official ? if not can somebody send me the
> > version so I can check hwo is workiing on my side because until now I
can
> > hear only noise and when Is start to ear the sound it will have many
delay
> > maybe this can help me thansk Roberto
> >
> > ----- Original Message ----- 
> > From: "Brad Midgley" <bmidgley@xmission.com>
> > To: <bluez-devel@lists.sourceforge.net>
> > Sent: Monday, August 29, 2005 7:08 PM
> > Subject: Re: [Bluez-devel] sbc and fixed-point progress
> >
> >
> >
> >>Roberto,
> >>
> >>If you follow the instructions at http://bluetooth-alsa.sf.net it will
> >>tell you how to use cvs to check out the current code including fixed
> >>point. (I will not be making a regular release until we nail down a few
> >>more things)
> >>
> >>Brad
> >>
> >>Roberto wrote:
> >>
> >>>Hi All/Victor,
> >>>
> >>>I want to check the latestversion of SBC on mobile can somebody tell me
> >
> > how
> >
> >>>we can get this version ? it is uopdated on the site ? which versioni
is
> >
> > ?
> >
> >>>Thanks Roberto
> >>>
> >>>----- Original Message ----- 
> >>>From: "Victor Shcherbatyuk" <victor@win.tue.nl>
> >>>To: <bluez-devel@lists.sourceforge.net>
> >>>Sent: Monday, August 29, 2005 12:26 AM
> >>>Subject: Re: [Bluez-devel] sbc and fixed-point progress
> >>>
> >>>
> >>>
> >>>
> >>>>Brad,
> >>>>
> >>>>I've merged the fixed and floating point code added 32-bit fixed point
> >>>
> >>>(not
> >>>
> >>>
> >>>>tested though), moved fixed point math to sbc_math.h. I've decided to
> >
> > use
> >
> >>>>struct to keep hi and low parts of 64bit number, but now I'm stuck
with
> >>>
> >>>make
> >>>
> >>>
> >>>>it alighned onto 4 bytes boundary (I've tried __attribute__ ((alighned
> >>>
> >>>(4),
> >>>
> >>>
> >>>>packed)) with the struct, but it does not help, apparently I'm missing
> >>>>something :) ), so currently everything is loaded byte-wise which is
> >>>>slow.... I'll try to ressolve the issue and then submit the changes...
> >>>>
> >>>>Regards,
> >>>>    Victor.
> >>>>
> >>>>
> >>>>----- Original Message ----- 
> >>>>From: "Brad Midgley" <bmidgley@xmission.com>
> >>>>To: <bluez-devel@lists.sourceforge.net>
> >>>>Sent: Sunday, August 28, 2005 07:44
> >>>>Subject: Re: [Bluez-devel] sbc and fixed-point progress
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Victor,
> >>>>>
> >>>>>Sorry... reapplied. I had thought this was one of my own fixed-point
> >>>>>tests. Thanks for keeping an eye on it.
> >>>>>
> >>>>>BTW, I started unrolling the decoder on paper and there's a ton of
room
> >>>>>for optimization. I'll rewrite it in floating point to start with.
> >>>>>
> >>>>>Brad
> >>>>>
> >>>>>
> >>>>>
> >>>>>>For some reason a piece of code from my initial patch is missing for
> >>>
> >>>cvs
> >>>
> >>>
> >>>>>>repository after the last updates... It is performance critical...
> >
> > I've
> >
> >>>>>>attached the patch to bring it back. Or it was removed on purpose?
> >>>>>>
> >>>>>>Regards,
> >>>>>>    Victor.
> >>>>>>
> >>>>>>----- Original Message ----- From: "Brad Midgley"
> >>>
> >>><bmidgley@xmission.com>
> >>>
> >>>>>>To: <bluez-devel@lists.sourceforge.net>
> >>>>>>Sent: Friday, August 26, 2005 07:10
> >>>>>>Subject: Re: [Bluez-devel] sbc and fixed-point progress
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Victor,
> >>>>>>>
> >>>>>>>How did you compute the floating point _anamatrix8[] and
> >>>
> >>>_sbc_proto_8[]
> >>>
> >>>
> >>>>>>>in sbc_tables.h? (I am trying to improve the 4-subband code based
on
> >>>>>>>your 8-subband float and fixed code.)
> >>>>>>>
> >>>>>>>BTW, I pulled out the testcode for fixed-point decoding now that
> >>>
> >>>people
> >>>
> >>>
> >>>>>>>will compile with fixed point enabled and expect everything to
work.
> >>>>>>>
> >>>>>>>thanks
> >>>>>>>Brad
> >>>>>>>
> >>>>>>>Victor Shcherbatyuk wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>Brad,
> >>>>>>>>
> >>>>>>>>I ran one more test and instead of -n flag for a2play I changed
> >
> > magic
> >
> >>>>>>>>87 to magic 50, CPU usage dropped >2 times to ~8% on ARM9@400Mhz
and
> >>>>>>>>sound is still smooth. That's how it was tested in first place
which
> >>>
> >>>is
> >>>
> >>>
> >>>>>>>>close to 30 MIPS I guess...
> >>>>>>>>
> >>>>>>>>Regards,
> >>>>>>>>   Victor.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>-----Original Message-----
> >>>>>>>>From: bluez-devel-admin@lists.sourceforge.net on behalf of Victor
> >>>>>>>>Shcherbatyuk
> >>>>>>>>Sent: Tue 8/23/2005 5:00 PM
> >>>>>>>>To: bluez-devel@lists.sourceforge.net
> >>>>>>>>Subject: RE: [Bluez-devel] sbc and fixed-point progress
> >>>>>>>>Hello Brad,
> >>>>>>>>
> >>>>>>>>I did some test runs on ARM9@400MHz, general fixed point encoder
> >
> > eats
> >
> >>>>>>>>up ~40% of CPU time, while arm specific version  - ~20%. And in
both
> >>>>>>>>cases it runs quite smooth. So the drops you had should have been
> >>>>>>>>caused by something else (unless you run some othe applications
> >>>>>>>>cuncurently).
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>Victor.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>-----Original Message-----
> >>>>>>>>From: bluez-devel-admin@lists.sourceforge.net on behalf of Brad
> >>>
> >>>Midgley
> >>>
> >>>
> >>>>>>>>Sent: Mon 8/22/2005 9:22 AM
> >>>>>>>>To: bluez-devel@lists.sourceforge.net
> >>>>>>>>Subject: Re: [Bluez-devel] sbc and fixed-point progress
> >>>>>>>>Victor
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>I do not have HW to test arm specific version real time, hope no
> >>>>>>>>>>suprises there, but I could have missed something when
integrating
> >>>
> >>>it
> >>>
> >>>
> >>>>>>>>>>into sbc code (it decodes well, but how fast, I will try only
> >>>
> >>>monday
> >>>
> >>>
> >>>>>>>>>>evening).
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>Ok, I'll load it on gumstix now and give it a try.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>This is almost perfect. On a 400mhz gumstix (pxa255), I'm able to
> >>>
> >>>send
> >>>
> >>>
> >>>>>>>>a 5-minute audio stream with only about three breaks in the audio
> >>>>>>>>(about 5 seconds each).
> >>>>>>>>
> >>>>>>>>I think it will work flawlessly in 4 subbands or if we can shorten
a
> >>>>>>>>few of the ops from 64 to 32 bit.
> >>>>>>>>
> >>>>>>>>I committed what's there and used __arm__ for the conditional asm
> >>>
> >>>code.
> >>>
> >>>
> >>>>>>>>>>Using a2play needs to tweak 87 magic number, otherwise it drops
> >>>>>>>>>>samples?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>yes, this is disappointing. We may need to find another way to
get
> >>>>>>>>>reliable timing than setitimer.
> >>>>>>>>>
> >>>>>>>>>I did change the first usleep(10) to usleep(1000) and that *may*
> >>>
> >>>help
> >>>
> >>>
> >>>>>>>>>with this problem by ensuring that we always interrupt the usleep
> >>>>>>>>>syscall consistently. I don't have my hp headphones (the set
that's
> >>>>>>>>>very sensitive to timing) handy to test.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>fwiw, I had to use the -n flag to a2play so it wouldn't use itimer
> >
> > at
> >
> >>>>>>>>all. This flag tells a2play to just send the audio as fast as it
can
> >>>>>>>>encode it.
> >>>>>>>>
> >>>>>>>>Brad
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>-------------------------------------------------------
> >>>>>>>>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
> >
> >>>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
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

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

[Victor Shcherbatyuk]

[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]

Brad,

The patch includes restructured and cleaned up code for 8-subband fixed 
point encoder (I didn't touch a2play yet). I've removed some of your code 
(if you need it let me know), moved fixed tables to sbc_tables.h (manually), 
merged floating and fixed point filter code. Now all the math is in 
sbc_math.h, an option added for 32 bit fixed point, but I could not make it 
sound any good, it is uses ~0% cpu producing sound of 0 quality - looks 
fair, so if someone wants to experiment with it... :)

I will do 4 subband encoder too. Can not promise any dates, depends how easy 
it goes...

I've played with Philips codec and I've noticed one thing. With the same 
value of bitpool our codec produces bitrate half of what the Philips codec 
does... So, if I set bitpool 15 for the Philips codec it will produce the 
same bitrate and sound quality as our encoder produces with bitpool eq. 32 - 
something might be wrong with bitallocation?

Regards,
      Victor.

P.S. There is no real need in rmagnitude() as we can test the filter code 
for overflowing using an test app, supplying all kind of inputs and 
comparing its output with that of the floating point filer. I've done it and 
currently it does not overflow, later if we need more precision? we can 
tweak SCALE_STAGE1 and SCALE_STAGE2 to get maximum of precision without 
overflowing....

[-- Attachment #2: sbc_fixed.patch --]
[-- Type: application/octet-stream, Size: 46999 bytes --]

? sbc/sbc_math.h
Index: sbc/gen_fixed.c
===================================================================
RCS file: /cvsroot/bluetooth-alsa/btsco/sbc/gen_fixed.c,v
retrieving revision 1.5
diff -u -r1.5 gen_fixed.c
--- sbc/gen_fixed.c	27 Aug 2005 02:17:54 -0000	1.5
+++ sbc/gen_fixed.c	3 Sep 2005 14:57:05 -0000
@@ -1,5 +1,3 @@
-#define USE_FIXED
-
 #include <math.h>
 #include "sbc.h"
 #include "sbc_tables.h"
@@ -10,16 +8,15 @@
 	int i;
 	int j;
 	int bits;
+	char* scalestr;
 } tables[] = {
 	//{"sbc_proto_4_40_f", (void *)sbc_proto_4_40, 40, 1, 28},
 	//{"sbc_proto_8_80_f", (void *)sbc_proto_8_80, 80, 1, 28},
-	{"synmatrix4_f", (void *)synmatrix4, 8, 4, 28},
-	{"synmatrix8_f", (void *)synmatrix8, 16, 8, 28},
+// 	{"synmatrix4_f", (void *)synmatrix4, 8, 4, 28},
+// 	{"synmatrix8_f", (void *)synmatrix8, 16, 8, 28},
 	//{"anamatrix4_f", (void *)anamatrix4, 4, 8, 28},
-	{"_sbc_proto_8_f", (void *)_sbc_proto_8, 40, 1, 33},
-	{"_anamatrix8_f", (void *)_anamatrix8, 8, 1, 30},
-	{"_sbc_proto_4_f", (void *)_sbc_proto_4, 20, 1, 33},
-	{"_anamatrix4_f", (void *)_anamatrix4, 4, 1, 30},
+	{"_sbc_proto_8", (void *)_sbc_proto_8, 40, 1, 33, "SP8"},
+	{"_anamatrix8", (void *)_anamatrix8, 8, 1, 30, "SA8"},
 	{0, 0, 0, 0}
 };
 
@@ -29,10 +26,6 @@
 	for(entry = 0; tables[entry].name; entry++) {
 		if(tables[entry].j == 1) {
 			if (tables[entry].ref == (void *)_sbc_proto_8 || tables[entry].ref == (void *)_anamatrix8) {
-				if (tables[entry].ref == (void *)_sbc_proto_8)
-					printf("#define FIXED64_STAGE1 %d\n", 24);
-				else
-					printf("#define FIXED64_STAGE2 %d\n", 7);
 				printf("static const int32_t %s[%d] = {\n",
 				       tables[entry].name, tables[entry].i);
 			}
@@ -54,7 +47,10 @@
 					printf("OVERFLOW (%f)!\n", res);
 					exit(1);
 				}
-				printf("0x%08x", (int32_t)res);
+				if (tables[entry].scalestr)
+					printf("%s(0x%08x)", tables[entry].scalestr, (int32_t)res);
+				else
+					printf("0x%08x", (int32_t)res);
 			}
 			printf("\n};\n\n");
 		} else {
Index: sbc/sbc.c
===================================================================
RCS file: /cvsroot/bluetooth-alsa/btsco/sbc/sbc.c,v
retrieving revision 1.53
diff -u -r1.53 sbc.c
--- sbc/sbc.c	28 Aug 2005 05:32:19 -0000	1.53
+++ sbc/sbc.c	3 Sep 2005 14:57:06 -0000
@@ -58,80 +58,9 @@
 #include <sys/types.h>
 
 #include "sbc.h"
+#include "sbc_math.h"
 #include "sbc_tables.h"
 
-#define fabs(x) ((x) < 0 ?-(x) : (x))
-
-#ifdef USE_FIXED
-#include "sbc_tables_f.h"
-
-static int assertf(int debug, float a, sbc_fixed_t b, char *msg) {
-	float c = fixedtod(b);
-	float diff = fabs(a-c);
-	if(fabs(diff/a) > 0.2 && diff > 0.5) {
-		fprintf(stderr, "compare failed float=%f fixed=%f in %s\n", a, c, msg);
-		if(debug) return 1;
-		exit(1);
-	} else if(debug == 1 && fabs(a) + fabs(c) > 0.001) {
-		fprintf(stderr, "float=%8.8f fixed=%8.8f in %s\n", a, c, msg);
-	}
-	return 0;
-}
-#endif
-
-struct magnitude {
-	int min;
-	int max;
-	char *name;
-};
-
-/* 
- * record the magnitude range of a float over many samples
- */
-
-static void rmagnitude(float f, int idx, char *n) {
-#if 0
-	static struct magnitude *mags = NULL;
-	f = fabs(f);
-	int m = 0;
-
-	// virtually zero
-	if(f < .0001) return;
-
-	if(mags == NULL) {
-		int size = sizeof(struct magnitude)*10;
-		mags = malloc(size);
-		memset(mags, 0, size);
-	}
-	if(idx < 0) {
-		printf("\n");
-		for(idx = 0; mags[idx].name != NULL; idx++)
-			printf("%s magnitude range is (%d,%d)\n", mags[idx].name, mags[idx].min, mags[idx].max);
-		return;
-	}
-	if(n == NULL) {
-		printf("%s magnitude range is (%d,%d)\n", mags[idx].name, mags[idx].min, mags[idx].max);
-		return;
-	}
-	while(f > 2.0) {
-		f/=2.0;
-		m++;
-	}
-	while(f < 1.0) {
-		f*=2.0;
-		m--;
-	}
-	if(m < mags[idx].min || mags[idx].min == 0) {
-		mags[idx].min = m;
-		mags[idx].name = n;
-	}
-	if(m > mags[idx].max || mags[idx].max == 0) {
-		mags[idx].max = m;
-		mags[idx].name = n;
-	}
-#endif
-}
-
 #define SBC_SYNCWORD 0x9C
 
 /* sampling frequency */
@@ -163,28 +92,26 @@
 /* This structure contains an unpacked SBC frame. 
    Yes, there is probably quite some unused space herein */
 struct sbc_frame {
-	u_int16_t sampling_frequency;	/* in kHz */
-	u_int8_t blocks;
+	uint16_t sampling_frequency;	/* in kHz */
+	uint8_t blocks;
 	enum {
 		MONO		= SBC_CM_MONO,
 		DUAL_CHANNEL	= SBC_CM_DUAL_CHANNEL,
 		STEREO		= SBC_CM_STEREO,
 		JOINT_STEREO	= SBC_CM_JOINT_STEREO
 	} channel_mode;
-	u_int8_t channels;
+	uint8_t channels;
 	enum {
 		LOUDNESS	= SBC_AM_LOUDNESS,
 		SNR		= SBC_AM_SNR
 	} allocation_method;
-	u_int8_t subbands;
-	u_int8_t bitpool;
-	u_int8_t join;				/* bit number x set means joint stereo has been used in subband x */
-	u_int8_t scale_factor[2][8];		/* only the lower 4 bits of every element are to be used */
-	u_int16_t audio_sample[16][2][8];	/* raw integer subband samples in the frame */
-#ifdef USE_FIXED
+	uint8_t subbands;
+	uint8_t bitpool;
+	uint8_t join;				/* bit number x set means joint stereo has been used in subband x */
+	uint8_t scale_factor[2][8];		/* only the lower 4 bits of every element are to be used */
+	uint16_t audio_sample[16][2][8];	/* raw integer subband samples in the frame */
+
 	sbc_fixed_t sb_sample_f[16][2][8];
-	sbc_fixed_t pcm_sample_f[2][16*8];
-#endif
 	double sb_sample[16][2][8];		/* modified subband samples */
 	int16_t pcm_sample[2][16*8];		/* original pcm audio samples */
 };
@@ -206,7 +133,7 @@
 /*
  * Calculates the CRC-8 of the first len bits in data
  */
-static const u_int8_t crc_table[256] = {
+static const uint8_t crc_table[256] = {
 	0x00, 0x1D, 0x3A, 0x27, 0x74, 0x69, 0x4E, 0x53,
 	0xE8, 0xF5, 0xD2, 0xCF, 0x9C, 0x81, 0xA6, 0xBB,
 	0xCD, 0xD0, 0xF7, 0xEA, 0xB9, 0xA4, 0x83, 0x9E,
@@ -241,11 +168,11 @@
 	0x97, 0x8A, 0xAD, 0xB0, 0xE3, 0xFE, 0xD9, 0xC4
 };
 
-static u_int8_t sbc_crc8(const u_int8_t * data, size_t len)
+static uint8_t sbc_crc8(const uint8_t * data, size_t len)
 {
-	u_int8_t crc = 0x0f;
+	uint8_t crc = 0x0f;
 	size_t i;
-	u_int8_t octet;
+	uint8_t octet;
 
 	for (i = 0; i < len / 8; i++)
 		crc = crc_table[crc ^ data[i]];
@@ -266,7 +193,7 @@
  * Code straight from the spec to calculate the bits array 
  * Takes a pointer to the frame in question, a pointer to the bits array and the sampling frequency (as 2 bit integer)
  */
-static void sbc_calculate_bits(const struct sbc_frame *frame, int (*bits)[8], u_int8_t sf)
+static void sbc_calculate_bits(const struct sbc_frame *frame, int (*bits)[8], uint8_t sf)
 {
 	if (frame->channel_mode == MONO || frame->channel_mode == DUAL_CHANNEL) {
 		int bitneed[2][8], loudness, max_bitneed, bitcount, slicecount, bitslice;
@@ -477,14 +404,14 @@
  *  -3   CRC8 incorrect
  *  -4   Bitpool value out of bounds
  */
-static int sbc_unpack_frame(const u_int8_t * data, struct sbc_frame *frame, size_t len)
+static int sbc_unpack_frame(const uint8_t * data, struct sbc_frame *frame, size_t len)
 {
 	int consumed;
 	/* Will copy the parts of the header that are relevant to crc calculation here */
-	u_int8_t crc_header[11] = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
+	uint8_t crc_header[11] = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
 	int crc_pos = 0;
 
-	u_int8_t sf;		/* sampling_frequency, temporarily needed as array index */
+	uint8_t sf;		/* sampling_frequency, temporarily needed as array index */
 
 	int ch, sb, blk, bit;	/* channel, subband, block and bit standard counters */
 	int bits[2][8];		/* bits distribution */
@@ -634,9 +561,6 @@
 					frame->sb_sample[blk][ch][sb] =
 						scalefactor[ch][sb] * ((frame->audio_sample[blk][ch][sb] * 2.0 + 1.0) /
 								       levels[ch][sb] - 1.0);
-					rmagnitude(frame->sb_sample[blk][ch][sb], 0, "frame->sb_sample[][][]");
-					rmagnitude(scalefactor[ch][sb], 1, "scalefactor[][]");
-					rmagnitude(levels[ch][sb], 2, "levels[][]");
 				} else {
 					frame->sb_sample[blk][ch][sb] = 0;
 				}
@@ -744,8 +668,6 @@
 		state->V[ch][k] = 0;
 		for (i = 0; i < 8; i++) {
 			state->V[ch][k] += synmatrix8[k][i] * state->S[ch][i];
-			rmagnitude(state->V[ch][k], 3, "state->V[ch][k]");
-			rmagnitude(synmatrix8[k][i], 7, "synmatrix8[k][i]");
 		}
 	}
 
@@ -754,15 +676,12 @@
 		for (j = 0; j < 8; j++) {
 			state->U[ch][i * 16 + j] = state->V[ch][i * 32 + j];
 			state->U[ch][i * 16 + j + 8] = state->V[ch][i * 32 + j + 24];
-			rmagnitude(state->U[ch][i * 16 + j], 4, "state->U[ch][i * 16 + j]");
 		}
 	}
 
 	/* Window by 80 coefficients */
 	for (i = 0; i < 80; i++) {
 		state->W[ch][i] = state->U[ch][i] * sbc_proto_8_80[i] * (-4);
-		rmagnitude(state->W[ch][i], 5, "state->W[ch][i]");
-		rmagnitude(sbc_proto_8_80[i]*4.0, 8, "sbc_proto_8_80[i]*4");
 	}
 
 	/* Calculate 8 audio samples */
@@ -770,7 +689,6 @@
 		state->X[ch][j] = 0;
 		for (i = 0; i < 10; i++) {
 			state->X[ch][j] += state->W[ch][j + 8 * i];
-			rmagnitude(state->X[ch][j], 6, "state->X[ch][j]");
 		}
 	}
 
@@ -821,20 +739,6 @@
 	state->subbands = frame->subbands;
 }
 
-#ifdef USE_FIXED
-static inline void _sbc_analyze_four(int32_t in[40], int32_t out[4])
-{
-}
-#else
-static inline void _sbc_analyze_four(int32_t in[40], double out[4])
-{
-	double t1,t2,t3,t4,t5,t6,t7,t8, in1, in2;
-	double a0,a1,a2,a3,a4,a5,a6,a7,a8,a9,a10,a11,a12,a13,a14,a15,a16,a17,a18,a19,a20;
-
-	out[0] = out[1] = out[2] = out[3] = 0;
-}
-#endif
-
 static inline void sbc_analyze_four(struct sbc_encoder_state *state,
 				struct sbc_frame *frame, int ch, int blk)
 {
@@ -845,11 +749,6 @@
 		state->X[ch][i] = state->X[ch][i - 4];
 	for (i = 3; i >= 0; i--)
 		state->X[ch][i] = frame->pcm_sample[ch][blk * 4 + (3 - i)];
-#ifdef USE_FIXED
-	_sbc_analyze_four(state->X[ch], frame->sb_sample_f[blk][ch]);
-#else
-	_sbc_analyze_four(state->X[ch], frame->sb_sample[blk][ch]);
-#endif
 
 	/* Windowing by 40 coefficients */
 	for (i = 0; i < 40; i++)
@@ -874,300 +773,174 @@
 		frame->sb_sample[blk][ch][i] = state->S[ch][i];
 }
 
-#ifdef USE_FIXED
-static inline void _sbc_analyze_eight(int32_t in[80], int32_t out[8])
+static inline void _sbc_analyze_eight(const int32_t in[80], sbc_fixed_t out[8])
 {
-	int32_t a0_hi,a1_hi,a2_hi,a3_hi,a4_hi,a5_hi,a6_hi,a7_hi,a8_hi,a9_hi,a10_hi,a11_hi,a12_hi,a13_hi,a14_hi,a15_hi,a16_hi,a17_hi,a18_hi,a19_hi,a20_hi, a21_hi;
-	int32_t a0_lo,a1_lo,a2_lo,a3_lo,a4_lo,a5_lo,a6_lo,a7_lo,a8_lo,a9_lo,a10_lo,a11_lo,a12_lo,a13_lo,a14_lo,a15_lo,a16_lo,a17_lo,a18_lo,a19_lo,a20_lo, a21_lo;
-	int32_t in1, in2, t1, t2, t3, t4, t5, t6, t7, t8;
-	int32_t t1_hi, t1_lo, t2_hi, t2_lo, t3_hi, t3_lo, t4_hi, t4_lo;
-	int32_t t5_hi, t5_lo, t6_hi, t6_lo, t7_hi, t7_lo, t8_hi, t8_lo;
-	int32_t out0_hi, out1_hi, out2_hi, out3_hi, out4_hi, out5_hi, out6_hi, out7_hi;
-	int32_t out0_lo, out1_lo, out2_lo, out3_lo, out4_lo, out5_lo, out6_lo, out7_lo;
-
-	t1_hi = t1_lo = t2_hi = t2_lo = t3_hi = t3_lo = t4_hi = t4_lo = 0;
-	t5_hi = t5_lo = t6_hi = t6_lo = t7_hi = t7_lo = t8_hi = t8_lo = 0;
-	out0_hi = out1_hi = out2_hi = out3_hi = out4_hi = out5_hi = out6_hi = out7_hi = 0;
-	out0_lo = out1_lo = out2_lo = out3_lo = out4_lo = out5_lo = out6_lo = out7_lo = 0;
-
-	in1 = in[16] - in[64]; in2 = in[32] - in[48];
-	MULA64(t1_hi, t1_lo, _sbc_proto_8_f[0], in1);
-	MULA64(t1_hi, t1_lo, _sbc_proto_8_f[1], in2);
-	MULA64(t1_hi, t1_lo, _sbc_proto_8_f[2], in[4]);
-	MULA64(t1_hi, t1_lo, _sbc_proto_8_f[3], in[20]);
-	MULA64(t1_hi, t1_lo, _sbc_proto_8_f[4], in[36]);
-	MULA64(t1_hi, t1_lo, _sbc_proto_8_f[5], in[52]);
-	t1 = SCALE64(t1_hi, t1_lo, FIXED64_STAGE1);
-
-	MULA64(t2_hi, t2_lo, _sbc_proto_8_f[6], in[2]);
-	MULA64(t2_hi, t2_lo, _sbc_proto_8_f[7], in[18]);
-	MULA64(t2_hi, t2_lo, _sbc_proto_8_f[8], in[34]);
-	MULA64(t2_hi, t2_lo, _sbc_proto_8_f[9], in[50]);
-	MULA64(t2_hi, t2_lo, _sbc_proto_8_f[10], in[66]);
-	t2 = SCALE64(t2_hi, t2_lo, FIXED64_STAGE1);
-
-	MULA64(t3_hi, t3_lo, _sbc_proto_8_f[11], in[1]);
-	MULA64(t3_hi, t3_lo, _sbc_proto_8_f[12], in[17]);
-	MULA64(t3_hi, t3_lo, _sbc_proto_8_f[13], in[33]);
-	MULA64(t3_hi, t3_lo, _sbc_proto_8_f[14], in[49]);
-	MULA64(t3_hi, t3_lo, _sbc_proto_8_f[15], in[65]);
-	MULA64(t3_hi, t3_lo, _sbc_proto_8_f[16], in[3]);
-	MULA64(t3_hi, t3_lo, _sbc_proto_8_f[17], in[19]);
-	MULA64(t3_hi, t3_lo, _sbc_proto_8_f[18], in[35]);
-	MULA64(t3_hi, t3_lo, _sbc_proto_8_f[19], in[51]);
-	MULA64(t3_hi, t3_lo, _sbc_proto_8_f[20], in[67]);
-	t3 = SCALE64(t3_hi, t3_lo, FIXED64_STAGE1);
-
-	MULA64(t4_hi, t4_lo, _sbc_proto_8_f[21], in[5]);
-	MULA64(t4_hi, t4_lo, _sbc_proto_8_f[22], in[21]);
-	MULA64(t4_hi, t4_lo, _sbc_proto_8_f[23], in[37]);
-	MULA64(t4_hi, t4_lo, _sbc_proto_8_f[24], in[53]);
-	MULA64(t4_hi, t4_lo, _sbc_proto_8_f[25], in[69]);
-	MULA64(t4_hi, t4_lo, -_sbc_proto_8_f[15], in[15]);
-	MULA64(t4_hi, t4_lo, -_sbc_proto_8_f[14], in[31]);
-	MULA64(t4_hi, t4_lo, -_sbc_proto_8_f[13], in[47]);
-	MULA64(t4_hi, t4_lo, -_sbc_proto_8_f[12], in[63]);
-	MULA64(t4_hi, t4_lo, -_sbc_proto_8_f[11], in[79]);
-	t4 = SCALE64(t4_hi, t4_lo, FIXED64_STAGE1);
-
-	MULA64(t5_hi, t5_lo, _sbc_proto_8_f[26], in[6]);
-	MULA64(t5_hi, t5_lo, _sbc_proto_8_f[27], in[22]);
-	MULA64(t5_hi, t5_lo, _sbc_proto_8_f[28], in[38]);
-	MULA64(t5_hi, t5_lo, _sbc_proto_8_f[29], in[54]);
-	MULA64(t5_hi, t5_lo, _sbc_proto_8_f[30], in[70]);
-	MULA64(t5_hi, t5_lo, -_sbc_proto_8_f[10], in[14]);
-	MULA64(t5_hi, t5_lo, -_sbc_proto_8_f[9], in[30]);
-	MULA64(t5_hi, t5_lo, -_sbc_proto_8_f[8], in[46]);
-	MULA64(t5_hi, t5_lo, -_sbc_proto_8_f[7], in[62]);
-	MULA64(t5_hi, t5_lo, -_sbc_proto_8_f[6], in[78]);
-	t5 = SCALE64(t5_hi, t5_lo, FIXED64_STAGE1);
-
-	MULA64(t6_hi, t6_lo, _sbc_proto_8_f[31], in[7]);
-	MULA64(t6_hi, t6_lo, _sbc_proto_8_f[32], in[23]);
-	MULA64(t6_hi, t6_lo, _sbc_proto_8_f[33], in[39]);
-	MULA64(t6_hi, t6_lo, _sbc_proto_8_f[34], in[55]);
-	MULA64(t6_hi, t6_lo, _sbc_proto_8_f[35], in[71]);
-	MULA64(t6_hi, t6_lo, -_sbc_proto_8_f[20], in[13]);
-	MULA64(t6_hi, t6_lo, -_sbc_proto_8_f[19], in[29]);
-	MULA64(t6_hi, t6_lo, -_sbc_proto_8_f[18], in[45]);
-	MULA64(t6_hi, t6_lo, -_sbc_proto_8_f[17], in[61]);
-	MULA64(t6_hi, t6_lo, -_sbc_proto_8_f[16], in[77]);
-	t6 = SCALE64(t6_hi, t6_lo, FIXED64_STAGE1);
-
-	in1 = in[8] + in[72];
-	MULA64(t7_hi, t7_lo, _sbc_proto_8_f[36], in1);
-	MULA64(t7_hi, t7_lo, _sbc_proto_8_f[37], in[24]);
-	MULA64(t7_hi, t7_lo, _sbc_proto_8_f[38], in[40]);
-	MULA64(t7_hi, t7_lo, _sbc_proto_8_f[37], in[56]);
-	MULA64(t7_hi, t7_lo, -_sbc_proto_8_f[39], in[12]);
-	MULA64(t7_hi, t7_lo, -_sbc_proto_8_f[5], in[28]);
-	MULA64(t7_hi, t7_lo, -_sbc_proto_8_f[4], in[44]);
-	MULA64(t7_hi, t7_lo, -_sbc_proto_8_f[3], in[60]);
-	MULA64(t7_hi, t7_lo, -_sbc_proto_8_f[2], in[76]);
-	t7 = SCALE64(t7_hi, t7_lo, FIXED64_STAGE1);
-
-	MULA64(t8_hi, t8_lo, _sbc_proto_8_f[35], in[9]);
-	MULA64(t8_hi, t8_lo, _sbc_proto_8_f[34], in[25]);
-	MULA64(t8_hi, t8_lo, _sbc_proto_8_f[33], in[41]);
-	MULA64(t8_hi, t8_lo, _sbc_proto_8_f[32], in[57]);
-	MULA64(t8_hi, t8_lo, _sbc_proto_8_f[31], in[73]);
-	MULA64(t8_hi, t8_lo, -_sbc_proto_8_f[25], in[11]);
-	MULA64(t8_hi, t8_lo, -_sbc_proto_8_f[24], in[27]);
-	MULA64(t8_hi, t8_lo, -_sbc_proto_8_f[23], in[43]);
-	MULA64(t8_hi, t8_lo, -_sbc_proto_8_f[22], in[59]);
-	MULA64(t8_hi, t8_lo, -_sbc_proto_8_f[21], in[75]);
-	t8 = SCALE64(t8_hi, t8_lo, FIXED64_STAGE1);
-
-	MUL64(a0_hi, a0_lo, _anamatrix8_f[0], t1);
-	MUL64(a7_hi, a7_lo, _anamatrix8_f[1], t1);
-	ADD64(out0_hi, out0_lo, a0_hi, a0_lo);
-	ADD64(out7_hi, out7_lo, a0_hi, a0_lo);
-	SUB64(out3_hi, out3_lo, a0_hi, a0_lo);
-	SUB64(out4_hi, out4_lo, a0_hi, a0_lo);
-	ADD64(out1_hi, out1_lo, a7_hi, a7_lo);
-	ADD64(out6_hi, out6_lo, a7_hi, a7_lo);
-	SUB64(out5_hi, out5_lo, a7_hi, a7_lo);
-	SUB64(out2_hi, out2_lo, a7_hi, a7_lo);
-
-	MUL64(a21_hi, a21_lo, _anamatrix8_f[7], t2);
-	ADD64(out0_hi, out0_lo, a21_hi, a21_lo);
-	ADD64(out1_hi, out1_lo, a21_hi, a21_lo);
-	ADD64(out2_hi, out2_lo, a21_hi, a21_lo);
-	ADD64(out3_hi, out3_lo, a21_hi, a21_lo);
-	ADD64(out4_hi, out4_lo, a21_hi, a21_lo);
-	ADD64(out5_hi, out5_lo, a21_hi, a21_lo);
-	ADD64(out6_hi, out6_lo, a21_hi, a21_lo);
-	ADD64(out7_hi, out7_lo, a21_hi, a21_lo);
-
-	MUL64(a1_hi, a1_lo, _anamatrix8_f[2], t3);
-	MUL64(a8_hi, a8_lo, _anamatrix8_f[3], t3);
-	MUL64(a13_hi, a13_lo, _anamatrix8_f[4], t3);
-	MUL64(a17_hi, a17_lo, _anamatrix8_f[5], t3);
-	ADD64(out0_hi, out0_lo, a1_hi, a1_lo);
-	SUB64(out7_hi, out7_lo, a1_hi, a1_lo);
-	ADD64(out1_hi, out1_lo, a8_hi, a8_lo);
-	SUB64(out6_hi, out6_lo, a8_hi, a8_lo);
-	ADD64(out2_hi, out2_lo, a13_hi, a13_lo);
-	SUB64(out5_hi, out5_lo, a13_hi, a13_lo);
-	ADD64(out3_hi, out3_lo, a17_hi, a17_lo);
-	SUB64(out4_hi, out4_lo, a17_hi, a17_lo);
-
-	MUL64(a2_hi, a2_lo, _anamatrix8_f[3], t4);
-	MUL64(a9_hi, a9_lo, _anamatrix8_f[5], t4);
-	MUL64(a14_hi, a14_lo, _anamatrix8_f[2], t4);
-	MUL64(a18_hi, a18_lo, _anamatrix8_f[4], t4);
-	ADD64(out0_hi, out0_lo, a2_hi, a2_lo);
-	SUB64(out7_hi, out7_lo, a2_hi, a2_lo);
-	SUB64(out1_hi, out1_lo, a9_hi, a9_lo);
-	ADD64(out6_hi, out6_lo, a9_hi, a9_lo);
-	SUB64(out2_hi, out2_lo, a14_hi, a14_lo);
-	ADD64(out5_hi, out5_lo, a14_hi, a14_lo);
-	SUB64(out3_hi, out3_lo, a18_hi, a18_lo);
-	ADD64(out4_hi, out4_lo, a18_hi, a18_lo);
-
-	MUL64(a3_hi, a3_lo, _anamatrix8_f[6], t5);
-	ADD64(out0_hi, out0_lo, a3_hi, a3_lo);
-	ADD64(out7_hi, out7_lo, a3_hi, a3_lo);
-	ADD64(out3_hi, out3_lo, a3_hi, a3_lo);
-	ADD64(out4_hi, out4_lo, a3_hi, a3_lo);
-	SUB64(out1_hi, out1_lo, a3_hi, a3_lo);
-	SUB64(out2_hi, out2_lo, a3_hi, a3_lo);
-	SUB64(out5_hi, out5_lo, a3_hi, a3_lo);
-	SUB64(out6_hi, out6_lo, a3_hi, a3_lo);
-
-	MUL64(a4_hi, a4_lo, _anamatrix8_f[4], t6);
-	MUL64(a10_hi, a10_lo, _anamatrix8_f[2], t6);
-	MUL64(a15_hi, a15_lo, _anamatrix8_f[5], t6);
-	MUL64(a19_hi, a19_lo, _anamatrix8_f[3], t6);
-	ADD64(out0_hi, out0_lo, a4_hi, a4_lo);
-	SUB64(out7_hi, out7_lo, a4_hi, a4_lo);
-	SUB64(out1_hi, out1_lo, a10_hi, a10_lo);
-	ADD64(out6_hi, out6_lo, a10_hi, a10_lo);
-	ADD64(out2_hi, out2_lo, a15_hi, a15_lo);
-	SUB64(out5_hi, out5_lo, a15_hi, a15_lo);
-	ADD64(out3_hi, out3_lo, a19_hi, a19_lo);
-	SUB64(out4_hi, out4_lo, a19_hi, a19_lo);
-
-	MUL64(a5_hi, a5_lo, _anamatrix8_f[1], t7);
-	MUL64(a11_hi, a11_lo, _anamatrix8_f[0], t7);
-	ADD64(out0_hi, out0_lo, a5_hi, a5_lo);
-	ADD64(out7_hi, out7_lo, a5_hi, a5_lo);
-	SUB64(out3_hi, out3_lo, a5_hi, a5_lo);
-	SUB64(out4_hi, out4_lo, a5_hi, a5_lo);
-	SUB64(out1_hi, out1_lo, a11_hi, a11_lo);
-	SUB64(out6_hi, out6_lo, a11_hi, a11_lo);
-	ADD64(out2_hi, out2_lo, a11_hi, a11_lo);
-	ADD64(out5_hi, out5_lo, a11_hi, a11_lo);
-
-	MUL64(a6_hi, a6_lo, _anamatrix8_f[5], t8);
-	MUL64(a12_hi, a12_lo, _anamatrix8_f[4], t8);
-	MUL64(a16_hi, a16_lo, _anamatrix8_f[3], t8);
-	MUL64(a20_hi, a20_lo, _anamatrix8_f[2], t8);
-	ADD64(out0_hi, out0_lo, a6_hi, a6_lo);
-	SUB64(out7_hi, out7_lo, a6_hi, a6_lo);
-	SUB64(out1_hi, out1_lo, a12_hi, a12_lo);
-	ADD64(out6_hi, out6_lo, a12_hi, a12_lo);
-	ADD64(out2_hi, out2_lo, a16_hi, a16_lo);
-	SUB64(out5_hi, out5_lo, a16_hi, a16_lo);
-	SUB64(out3_hi, out3_lo, a20_hi, a20_lo);
-	ADD64(out4_hi, out4_lo, a20_hi, a20_lo);
-
-	// restore original scale
-	out[0] = out0_hi >> FIXED64_STAGE2;
-	out[1] = out1_hi >> FIXED64_STAGE2;
-	out[2] = out2_hi >> FIXED64_STAGE2;
-	out[3] = out3_hi >> FIXED64_STAGE2;
-	out[4] = out4_hi >> FIXED64_STAGE2;
-	out[5] = out5_hi >> FIXED64_STAGE2;
-	out[6] = out6_hi >> FIXED64_STAGE2;
-	out[7] = out7_hi >> FIXED64_STAGE2;
+	sbc_fixed_t res;
+	int32_t t1, t2, t3, t4, t5, t6, t7, t8;
 
-}
-#else
-static inline void _sbc_analyze_eight(int32_t in[80], double out[8])
-{
-	double t1,t2,t3,t4,t5,t6,t7,t8, in1, in2;
-	double a0,a1,a2,a3,a4,a5,a6,a7,a8,a9,a10,a11,a12,a13,a14,a15,a16,a17,a18,a19,a20;
+	SBC_FIXED_0(out[0]);SBC_FIXED_0(out[1]);SBC_FIXED_0(out[2]);SBC_FIXED_0(out[3]);
+	SBC_FIXED_0(out[4]);SBC_FIXED_0(out[5]);SBC_FIXED_0(out[6]);SBC_FIXED_0(out[7]);
+
+	MUL(res, _sbc_proto_8[0], (in[16] - in[64]));
+	MULA(res, _sbc_proto_8[1], (in[32] - in[48]));
+	MULA(res, _sbc_proto_8[2], in[4]);
+	MULA(res, _sbc_proto_8[3], in[20]);
+	MULA(res, _sbc_proto_8[4], in[36]);
+	MULA(res, _sbc_proto_8[5], in[52]);
+	t1 = SCALE_STAGE1(res);
+
+	MUL(res, _sbc_proto_8[6], in[2]);
+	MULA(res, _sbc_proto_8[7], in[18]);
+	MULA(res, _sbc_proto_8[8], in[34]);
+	MULA(res, _sbc_proto_8[9], in[50]);
+	MULA(res, _sbc_proto_8[10], in[66]);
+	t2 = SCALE_STAGE1(res);
+
+	MUL(res, _sbc_proto_8[11], in[1]);
+	MULA(res, _sbc_proto_8[12], in[17]);
+	MULA(res, _sbc_proto_8[13], in[33]);
+	MULA(res, _sbc_proto_8[14], in[49]);
+	MULA(res, _sbc_proto_8[15], in[65]);
+	MULA(res, _sbc_proto_8[16], in[3]);
+	MULA(res, _sbc_proto_8[17], in[19]);
+	MULA(res, _sbc_proto_8[18], in[35]);
+	MULA(res, _sbc_proto_8[19], in[51]);
+	MULA(res, _sbc_proto_8[20], in[67]);
+	t3 = SCALE_STAGE1(res);
+
+	MUL(res, _sbc_proto_8[21], in[5]);
+	MULA(res, _sbc_proto_8[22], in[21]);
+	MULA(res, _sbc_proto_8[23], in[37]);
+	MULA(res, _sbc_proto_8[24], in[53]);
+	MULA(res, _sbc_proto_8[25], in[69]);
+	MULA(res, -_sbc_proto_8[15], in[15]);
+	MULA(res, -_sbc_proto_8[14], in[31]);
+	MULA(res, -_sbc_proto_8[13], in[47]);
+	MULA(res, -_sbc_proto_8[12], in[63]);
+	MULA(res, -_sbc_proto_8[11], in[79]);
+	t4 = SCALE_STAGE1(res);
+
+	MUL(res, _sbc_proto_8[26], in[6]);
+	MULA(res, _sbc_proto_8[27], in[22]);
+	MULA(res, _sbc_proto_8[28], in[38]);
+	MULA(res, _sbc_proto_8[29], in[54]);
+	MULA(res, _sbc_proto_8[30], in[70]);
+	MULA(res, -_sbc_proto_8[10], in[14]);
+	MULA(res, -_sbc_proto_8[9], in[30]);
+	MULA(res, -_sbc_proto_8[8], in[46]);
+	MULA(res, -_sbc_proto_8[7], in[62]);
+	MULA(res, -_sbc_proto_8[6], in[78]);
+	t5 = SCALE_STAGE1(res);
+
+	MUL(res, _sbc_proto_8[31], in[7]);
+	MULA(res, _sbc_proto_8[32], in[23]);
+	MULA(res, _sbc_proto_8[33], in[39]);
+	MULA(res, _sbc_proto_8[34], in[55]);
+	MULA(res, _sbc_proto_8[35], in[71]);
+	MULA(res, -_sbc_proto_8[20], in[13]);
+	MULA(res, -_sbc_proto_8[19], in[29]);
+	MULA(res, -_sbc_proto_8[18], in[45]);
+	MULA(res, -_sbc_proto_8[17], in[61]);
+	MULA(res, -_sbc_proto_8[16], in[77]);
+	t6 = SCALE_STAGE1(res);
+
+	MUL(res, _sbc_proto_8[36], (in[8] + in[72]));
+	MULA(res, _sbc_proto_8[37], in[24]);
+	MULA(res, _sbc_proto_8[38], in[40]);
+	MULA(res, _sbc_proto_8[37], in[56]);
+	MULA(res, -_sbc_proto_8[39], in[12]);
+	MULA(res, -_sbc_proto_8[5], in[28]);
+	MULA(res, -_sbc_proto_8[4], in[44]);
+	MULA(res, -_sbc_proto_8[3], in[60]);
+	MULA(res, -_sbc_proto_8[2], in[76]);
+	t7 = SCALE_STAGE1(res);
+
+	MUL(res, _sbc_proto_8[35], in[9]);
+	MULA(res, _sbc_proto_8[34], in[25]);
+	MULA(res, _sbc_proto_8[33], in[41]);
+	MULA(res, _sbc_proto_8[32], in[57]);
+	MULA(res, _sbc_proto_8[31], in[73]);
+	MULA(res, -_sbc_proto_8[25], in[11]);
+	MULA(res, -_sbc_proto_8[24], in[27]);
+	MULA(res, -_sbc_proto_8[23], in[43]);
+	MULA(res, -_sbc_proto_8[22], in[59]);
+	MULA(res, -_sbc_proto_8[21], in[75]);
+	t8 = SCALE_STAGE1(res);
+
+	MUL(out[0], _anamatrix8[0], t1);
+	MULA(out[0], _anamatrix8[7], t2);
+	MULA(out[0], _anamatrix8[2], t3);
+	MULA(out[0], _anamatrix8[3], t4);
+	MULA(out[0], _anamatrix8[6], t5);
+	MULA(out[0], _anamatrix8[4], t6);
+	MULA(out[0], _anamatrix8[1], t7);
+	MULA(out[0], _anamatrix8[5], t8);
+
+	MUL(out[1], _anamatrix8[1], t1);
+	MULA(out[1], _anamatrix8[7], t2);
+	MULA(out[1], _anamatrix8[3], t3);
+	MULA(out[1], -_anamatrix8[5], t4);
+	MULA(out[1], -_anamatrix8[6], t5);
+	MULA(out[1], -_anamatrix8[2], t6);
+	MULA(out[1], -_anamatrix8[0], t7);
+	MULA(out[1], -_anamatrix8[4], t8);
+
+	MUL(out[2], -_anamatrix8[1], t1);
+	MULA(out[2], _anamatrix8[7], t2);
+	MULA(out[2], _anamatrix8[4], t3);
+	MULA(out[2], -_anamatrix8[2], t4);
+	MULA(out[2], -_anamatrix8[6], t5);
+	MULA(out[2], _anamatrix8[5], t6);
+	MULA(out[2], _anamatrix8[0], t7);
+	MULA(out[2], _anamatrix8[3], t8);
+
+	MUL(out[3], -_anamatrix8[0], t1);
+	MULA(out[3], _anamatrix8[7], t2);
+	MULA(out[3], _anamatrix8[5], t3);
+	MULA(out[3], -_anamatrix8[4], t4);
+	MULA(out[3], _anamatrix8[6], t5);
+	MULA(out[3], _anamatrix8[3], t6);
+	MULA(out[3], -_anamatrix8[1], t7);
+	MULA(out[3], -_anamatrix8[2], t8);
+
+	MUL(out[4], -_anamatrix8[0], t1);
+	MULA(out[4], _anamatrix8[7], t2);
+	MULA(out[4], -_anamatrix8[5], t3);
+	MULA(out[4], _anamatrix8[4], t4);
+	MULA(out[4], _anamatrix8[6], t5);
+	MULA(out[4], -_anamatrix8[3], t6);
+	MULA(out[4], -_anamatrix8[1], t7);
+	MULA(out[4], _anamatrix8[2], t8);
+
+	MUL(out[5], -_anamatrix8[1], t1);
+	MULA(out[5], _anamatrix8[7], t2);
+	MULA(out[5], -_anamatrix8[4], t3);
+	MULA(out[5], _anamatrix8[2], t4);
+	MULA(out[5], -_anamatrix8[6], t5);
+	MULA(out[5], -_anamatrix8[5], t6);
+	MULA(out[5], _anamatrix8[0], t7);
+	MULA(out[5], -_anamatrix8[3], t8);
+
+	MUL(out[6], _anamatrix8[1], t1);
+	MULA(out[6], _anamatrix8[7], t2);
+	MULA(out[6], -_anamatrix8[3], t3);
+	MULA(out[6], _anamatrix8[5], t4);
+	MULA(out[6], -_anamatrix8[6], t5);
+	MULA(out[6], _anamatrix8[2], t6);
+	MULA(out[6], -_anamatrix8[0], t7);
+	MULA(out[6], _anamatrix8[4], t8);
+
+	MUL(out[7], _anamatrix8[0], t1);
+	MULA(out[7], _anamatrix8[7], t2);
+	MULA(out[7], -_anamatrix8[2], t3);
+	MULA(out[7], -_anamatrix8[3], t4);
+	MULA(out[7], _anamatrix8[6], t5);
+	MULA(out[7], -_anamatrix8[4], t6);
+	MULA(out[7], _anamatrix8[1], t7);
+	MULA(out[7], -_anamatrix8[5], t8);
 
-	out[0] = out[1] = out[2] = out[3] = out[4] = out[5] = out[6] = out[7] = 0;
 
-	in1 = in[16] - in[64]; in2 = in[32] - in[48];
-	t1 = _sbc_proto_8[0]*in1 + _sbc_proto_8[1]*in2 +\
-	     _sbc_proto_8[2]*in[4] + _sbc_proto_8[3]*in[20] +  _sbc_proto_8[4]*in[36] +\
-	     _sbc_proto_8[5]*in[52];
-
-	t2 = _sbc_proto_8[6]*in[2] + _sbc_proto_8[7]*in[18] + \
-	     _sbc_proto_8[8]*in[34] + _sbc_proto_8[9]*in[50] + _sbc_proto_8[10]*in[66];
-
-	t3 = _sbc_proto_8[11]*in[1] + _sbc_proto_8[12]*in[17] + \
-	     _sbc_proto_8[13]*in[33] + _sbc_proto_8[14]*in[49] + _sbc_proto_8[15]*in[65] +\
-	     _sbc_proto_8[16]*in[3] + _sbc_proto_8[17]*in[19] + _sbc_proto_8[18]*in[35] +\
-	     _sbc_proto_8[19]*in[51] + _sbc_proto_8[20]*in[67];
-
-	t4 = _sbc_proto_8[21]*in[5] + _sbc_proto_8[22]*in[21] + \
-	     _sbc_proto_8[23]*in[37] + _sbc_proto_8[24]*in[53] + _sbc_proto_8[25]*in[69] -\
-	     _sbc_proto_8[15]*in[15] - _sbc_proto_8[14]*in[31] - _sbc_proto_8[13]*in[47] -\
-	     _sbc_proto_8[12]*in[63] - _sbc_proto_8[11]*in[79];
-
-	t5 = _sbc_proto_8[26]*in[6] + _sbc_proto_8[27]*in[22] + \
-	     _sbc_proto_8[28]*in[38] + _sbc_proto_8[29]*in[54] + _sbc_proto_8[30]*in[70] -\
-	     _sbc_proto_8[10]*in[14] - _sbc_proto_8[9]*in[30] - _sbc_proto_8[8]*in[46] -\
-	     _sbc_proto_8[7]*in[62] - _sbc_proto_8[6]*in[78];
-
-	t6 = _sbc_proto_8[31]*in[7] + _sbc_proto_8[32]*in[23] + \
-	     _sbc_proto_8[33]*in[39] + _sbc_proto_8[34]*in[55] + _sbc_proto_8[35]*in[71] -\
-	     _sbc_proto_8[20]*in[13] - _sbc_proto_8[19]*in[29] - _sbc_proto_8[18]*in[45] -\
-	     _sbc_proto_8[17]*in[61] - _sbc_proto_8[16]*in[77];
-
-	in1 = in[8] + in[72];
-	t7 = _sbc_proto_8[36]*in1 + _sbc_proto_8[37]*in[24] + \
-	     _sbc_proto_8[38]*in[40] + _sbc_proto_8[37]*in[56] - _sbc_proto_8[39]*in[12] -\
-	     _sbc_proto_8[5]*in[28] - _sbc_proto_8[4]*in[44] - _sbc_proto_8[3]*in[60] -\
-	     _sbc_proto_8[2]*in[76];
-
-	t8 = _sbc_proto_8[35]*in[9] + _sbc_proto_8[34]*in[25] + \
-	     _sbc_proto_8[33]*in[41] + _sbc_proto_8[32]*in[57] + _sbc_proto_8[31]*in[73] -\
-	     _sbc_proto_8[25]*in[11] - _sbc_proto_8[24]*in[27] -_sbc_proto_8[23]*in[43] -\
-	     _sbc_proto_8[22]*in[59] - _sbc_proto_8[21]*in[75];
-
-	a0 = _anamatrix8[0]*t1;
-	a7 = _anamatrix8[1]*t1;
-	out[0] += a0;	out[1] += a7;	out[2] -= a7;	out[3] -= a0;	out[4] -= a0;	out[5] -= a7;	out[6] += a7;	out[7] += a0;
-
-	out[0] += t2;	out[1] += t2;	out[2] += t2;	out[3] += t2;	out[4] += t2;	out[5] += t2;	out[6] += t2;	out[7] += t2;
-
-	a1 = _anamatrix8[2]*t3;
-	a8 = _anamatrix8[3]*t3;
-	a13 = _anamatrix8[4]*t3;
-	a17 = _anamatrix8[5]*t3;
-	out[0] += a1;	out[1] += a8;	out[2] += a13;	out[3] += a17;	out[4] -= a17;	out[5] -= a13;	out[6] -= a8;	out[7] -= a1;
-
-	a2 = _anamatrix8[3]*t4;
-	a9 = _anamatrix8[5]*t4;
-	a14 = _anamatrix8[2]*t4;
-	a18 = _anamatrix8[4]*t4;
-	out[0] += a2;	out[1] -= a9;	out[2] -= a14;	out[3] -= a18;	out[4] += a18;	out[5] += a14;	out[6] += a9;	out[7] -= a2;
-
-	a4 = _anamatrix8[4]*t6;
-	a10 = _anamatrix8[2]*t6;
-	a15 = _anamatrix8[5]*t6;
-	a19 = _anamatrix8[3]*t6;
-	out[0] += a4;	out[1] -= a10;	out[2] += a15;	out[3] += a19;	out[4] -= a19;	out[5] -= a15;	out[6] += a10;	out[7] -= a4;
-
-	a3 = _anamatrix8[6]*t5;
-	out[0] += a3;	out[1] -= a3;	out[2] -= a3;	out[3] += a3;	out[4] += a3;	out[5] -= a3;	out[6] -= a3;	out[7] += a3;
-
-	a5 = _anamatrix8[1]*t7;
-	a11 = _anamatrix8[0]*t7;
-	out[0] += a5;	out[1] -= a11;	out[2] += a11;	out[3] -= a5;	out[4] -= a5;	out[5] += a11;	out[6] -= a11;	out[7] += a5;
-
-	a6 = _anamatrix8[5]*t8;
-	a12 = _anamatrix8[4]*t8;
-	a16 = _anamatrix8[3]*t8;
-	a20 = _anamatrix8[2]*t8;
-	out[0] += a6;	out[1] -= a12;	out[2] += a16;	out[3] -= a20;	out[4] += a20;	out[5] -= a16;	out[6] += a12;	out[7] -= a6;
 }
-#endif
 
 static inline void sbc_analyze_eight(struct sbc_encoder_state *state,
 				     struct sbc_frame *frame, int ch, int blk)
@@ -1179,11 +952,7 @@
 		state->X[ch][i] = state->X[ch][i - 8];
 	for (i = 7; i >= 0; i--)
 		state->X[ch][i] = frame->pcm_sample[ch][blk * 8 + (7 - i)];
-#ifdef USE_FIXED
 	_sbc_analyze_eight(state->X[ch], frame->sb_sample_f[blk][ch]);
-#else
-	_sbc_analyze_eight(state->X[ch], frame->sb_sample[blk][ch]);
-#endif
 }
 
 static int sbc_analyze_audio(struct sbc_encoder_state *state, struct sbc_frame *frame)
@@ -1229,14 +998,14 @@
  * -99 not implemented
  */
 
-static int sbc_pack_frame(u_int8_t * data, struct sbc_frame *frame, size_t len)
+static int sbc_pack_frame(uint8_t * data, struct sbc_frame *frame, size_t len)
 {
 	int produced;
 	/* Will copy the header parts for CRC-8 calculation here */
-	u_int8_t crc_header[11] = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
+	uint8_t crc_header[11] = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
 	int crc_pos = 0;
 
-	u_int8_t sf;		/* Sampling frequency as temporary value for table lookup */
+	uint8_t sf;		/* Sampling frequency as temporary value for table lookup */
 
 	int ch, sb, blk, bit;	/* channel, subband, block and bit counters */
 	int bits[2][8];		/* bits distribution */
@@ -1325,11 +1094,7 @@
 			frame->scale_factor[ch][sb] = 0;
 			scalefactor[ch][sb] = 2;
 			for (blk = 0; blk < frame->blocks; blk++) {
-#ifdef USE_FIXED
-				while (scalefactor[ch][sb] < fabs(frame->sb_sample_f[blk][ch][sb])) {
-#else
-				while (scalefactor[ch][sb] < fabs(frame->sb_sample[blk][ch][sb])) {
-#endif
+				while (scalefactor[ch][sb] < fabs(SCALE_STAGE2(frame->sb_sample_f[blk][ch][sb]))) {
 					frame->scale_factor[ch][sb]++;
 					scalefactor[ch][sb] *= 2;
 				}
@@ -1337,69 +1102,74 @@
 		}
 	}
 
-	if (frame->channel_mode == JOINT_STEREO) {
-		float sb_sample_j[16][2][7]; /* like frame->sb_sample but joint stereo */
-		int scalefactor_j[2][7], scale_factor_j[2][7]; /* scalefactor and scale_factor in joint case */
-
-		/* Calculate joint stereo signal */
-		for (sb = 0; sb < frame->subbands - 1; sb++) {
+ 	if (frame->channel_mode == JOINT_STEREO) {
+		sbc_fixed_t sb_sample_j[16][2][7]; /* like frame->sb_sample but joint stereo */
+		sbc_fixed_t tmp;
+ 		int scalefactor_j[2][7], scale_factor_j[2][7]; /* scalefactor and scale_factor in joint case */
+ 
+ 		/* Calculate joint stereo signal */
+ 		for (sb = 0; sb < frame->subbands - 1; sb++) {
 			for (blk = 0; blk < frame->blocks; blk++) {
-				sb_sample_j[blk][0][sb] = (frame->sb_sample[blk][0][sb] 
-							   + frame->sb_sample[blk][1][sb]) / 2;
-				sb_sample_j[blk][1][sb] = (frame->sb_sample[blk][0][sb] 
-							   - frame->sb_sample[blk][1][sb]) / 2;
-			}
-		}
-
-		/* calculate scale_factor_j and scalefactor_j for joint case */
-		for (ch = 0; ch < 2; ch++) {
-			for (sb = 0; sb < frame->subbands - 1; sb++) {
-				scale_factor_j[ch][sb] = 0;
-				scalefactor_j[ch][sb] = 2;
-				for (blk = 0; blk < frame->blocks; blk++) {
-					while (scalefactor_j[ch][sb] < fabs(sb_sample_j[blk][ch][sb])) {
-						scale_factor_j[ch][sb]++;
-						scalefactor_j[ch][sb] *= 2;
-					}
-				}
-			}
-		}
-
-		/* decide which subbands to join */
-		frame->join = 0;
-		for (sb = 0; sb < frame->subbands - 1; sb++) {
-			if ( (scalefactor[0][sb] + scalefactor[1][sb]) > 
-			     (scalefactor_j[0][sb] + scalefactor_j[1][sb]) ) {
-				/* use joint stereo for this subband */
-				frame->join |= 1 << sb;
-				frame->scale_factor[0][sb] = scale_factor_j[0][sb];
-				frame->scale_factor[1][sb] = scale_factor_j[1][sb];
-				scalefactor[0][sb] = scalefactor_j[0][sb];
-				scalefactor[1][sb] = scalefactor_j[1][sb];
-				for (blk = 0; blk < frame->blocks; blk++) {
-					frame->sb_sample[blk][0][sb] = sb_sample_j[blk][0][sb];
-					frame->sb_sample[blk][1][sb] = sb_sample_j[blk][1][sb];
-				}
-			}
-		}
-  
-		if (len * 8 < produced + frame->subbands) {
-			return -1;
-		} else {
-			data[4] = 0;
-			for (sb = 0; sb < frame->subbands - 1; sb++) {
-				data[4] |= ((frame->join >> sb) & 0x01) << (7 - sb);
-			}
-			if (frame->subbands == 4) {
-				crc_header[crc_pos / 8] = data[4] & 0xf0;
-			} else {
-				crc_header[crc_pos / 8] = data[4];
-			}
-
-			produced += frame->subbands;
-			crc_pos += frame->subbands;
-		}
-	}
+				tmp = frame->sb_sample_f[blk][0][sb];
+				ADD(tmp, frame->sb_sample_f[blk][1][sb]);
+				DIV2(sb_sample_j[blk][0][sb], tmp);				
+//  				sb_sample_j[blk][0][sb] = (frame->sb_sample_f[blk][0][sb] + frame->sb_sample_f[blk][1][sb]) / 2;
+				tmp = frame->sb_sample_f[blk][0][sb];
+				SUB(tmp, frame->sb_sample_f[blk][1][sb]);
+				DIV2(sb_sample_j[blk][1][sb], tmp);				
+//  				sb_sample_j[blk][1][sb] = (frame->sb_sample_f[blk][0][sb] - frame->sb_sample_f[blk][1][sb]) / 2;
+ 			}
+ 		}
+ 
+ 		/* calculate scale_factor_j and scalefactor_j for joint case */
+ 		for (ch = 0; ch < 2; ch++) {
+ 			for (sb = 0; sb < frame->subbands - 1; sb++) {
+ 				scale_factor_j[ch][sb] = 0;
+ 				scalefactor_j[ch][sb] = 2;
+ 				for (blk = 0; blk < frame->blocks; blk++) {
+ 					while (scalefactor_j[ch][sb] < fabs(SCALE_STAGE2(sb_sample_j[blk][ch][sb]))) {
+ 						scale_factor_j[ch][sb]++;
+ 						scalefactor_j[ch][sb] *= 2;
+ 					}
+ 				}
+ 			}
+ 		}
+ 
+ 		/* decide which subbands to join */
+ 		frame->join = 0;
+ 		for (sb = 0; sb < frame->subbands - 1; sb++) {
+ 			if ( (scalefactor[0][sb] + scalefactor[1][sb]) > 
+ 			     (scalefactor_j[0][sb] + scalefactor_j[1][sb]) ) {
+ 				/* use joint stereo for this subband */
+ 				frame->join |= 1 << sb;
+ 				frame->scale_factor[0][sb] = scale_factor_j[0][sb];
+ 				frame->scale_factor[1][sb] = scale_factor_j[1][sb];
+ 				scalefactor[0][sb] = scalefactor_j[0][sb];
+ 				scalefactor[1][sb] = scalefactor_j[1][sb];
+ 				for (blk = 0; blk < frame->blocks; blk++) {
+ 					frame->sb_sample_f[blk][0][sb] = sb_sample_j[blk][0][sb];
+ 					frame->sb_sample_f[blk][1][sb] = sb_sample_j[blk][1][sb];
+ 				}
+			}
+ 		}
+   
+ 		if (len * 8 < produced + frame->subbands) {
+ 			return -1;
+ 		} else {
+ 			data[4] = 0;
+ 			for (sb = 0; sb < frame->subbands - 1; sb++) {
+ 				data[4] |= ((frame->join >> sb) & 0x01) << (7 - sb);
+ 			}
+ 			if (frame->subbands == 4) {
+ 				crc_header[crc_pos / 8] = data[4] & 0xf0;
+ 			} else {
+ 				crc_header[crc_pos / 8] = data[4];
+ 			}
+ 
+ 			produced += frame->subbands;
+ 			crc_pos += frame->subbands;
+ 		}
+ 	}
 
 	if (len * 8 < produced + (4 * frame->subbands * frame->channels)) {
 		return -1;
@@ -1432,13 +1202,14 @@
 		for (ch = 0; ch < frame->channels; ch++) {
 			for (sb = 0; sb < frame->subbands; sb++) {
 				if (levels[ch][sb] > 0) {
+//PLEASECHECK: overflow possible? more elegant solution?
 #ifdef USE_FIXED
 					frame->audio_sample[blk][ch][sb] =
-						(u_int16_t) ((((frame->sb_sample_f[blk][ch][sb]*levels[ch][sb]) >> (frame->scale_factor[ch][sb] + 1)) +
+						(uint16_t) ((((SCALE_STAGE2(frame->sb_sample_f[blk][ch][sb])*levels[ch][sb]) >> (frame->scale_factor[ch][sb] + 1)) +
 						levels[ch][sb]) >> 1);
 #else
 					frame->audio_sample[blk][ch][sb] =
-						(u_int16_t) (((frame->sb_sample[blk][ch][sb] / scalefactor[ch][sb] +
+						(uint16_t) (((frame->sb_sample_f[blk][ch][sb] / scalefactor[ch][sb] +
 						1.0) * levels[ch][sb]) / 2.0);
 #endif
 				} else {
@@ -1512,7 +1283,6 @@
 	struct sbc_priv *priv;
 	char *ptr;
 	int i, ch, framelen, samples;
-	static int modulo = 0;
 
 	if (!sbc)
 		return -EIO;
@@ -1562,8 +1332,6 @@
 
 	sbc->len = samples * priv->frame.channels * 2;
 
-	if(modulo++ % 256 == 0) rmagnitude(1.0, -1, NULL);
-
 	return framelen;
 }
 
Index: sbc/sbc.h
===================================================================
RCS file: /cvsroot/bluetooth-alsa/btsco/sbc/sbc.h,v
retrieving revision 1.21
diff -u -r1.21 sbc.h
--- sbc/sbc.h	22 Aug 2005 07:11:14 -0000	1.21
+++ sbc/sbc.h	3 Sep 2005 14:57:06 -0000
@@ -29,8 +29,6 @@
 extern "C" {
 #endif
 
-#include <stdint.h>
-
 #define SBC_NULL	0x00000001
 
 struct sbc_struct {
@@ -53,90 +51,6 @@
 
 typedef struct sbc_struct sbc_t;
 
-#ifdef USE_FIXED
-
-typedef int32_t sbc_fixed_t;
-
-// this must be an even number
-#define FRAC 20
-
-// FRAC/2 leading ones for sign-extended shift
-#define PAD (0xffffffff<<(32-(FRAC>>1)))
-
-// FRAC/2 trailing ones for finding the roundoff portion
-#define RMASK (0xffffffff>>(32-(FRAC>>1)))
-
-#define FIXED_ONE (1<<FRAC)
-
-// sign-extend half the number of shift (fractional) bits
-static inline sbc_fixed_t signextshift(sbc_fixed_t i) { 
-	if(i<0) return (i>>(FRAC>>1)) | PAD;
-	return i>>(FRAC>>1); 
-}
-
-static inline sbc_fixed_t itofixed(int i) { return i<<FRAC; }
-
-static inline int fixedtoi(sbc_fixed_t f) { return f>>FRAC; }
-
-static inline sbc_fixed_t dtofixed(double d) { return (sbc_fixed_t)(d * (double)FIXED_ONE); }
-
-static inline double fixedtod(sbc_fixed_t f) { return f / (double)FIXED_ONE; }
-
-static inline sbc_fixed_t fxmultquick(sbc_fixed_t a, sbc_fixed_t b) { 
-	sbc_fixed_t p = signextshift(a)*signextshift(b);
-	return p;
-}
-
-static inline sbc_fixed_t fxmult(sbc_fixed_t a, sbc_fixed_t b) { 
-	// don't lose as much roundoff precision
-	sbc_fixed_t ad = signextshift(a);
-	sbc_fixed_t bd = signextshift(b);
-	sbc_fixed_t p = (ad * bd) + signextshift(ad * (b & RMASK)) + signextshift(bd * (a & RMASK));
-	return p;
-}
-
-//overflow problems?
-//static inline sbc_fixed_t fxdiv(sbc_fixed_t a, sbc_fixed_t b) { return (a<<FRAC)/b; }
-
-#define ADD64(dhi, dlo, shi, slo)  { dlo += slo; dhi += shi; if ( (unsigned long)dlo < (unsigned long)slo ) dhi++;}
-#define SUB64(dhi, dlo, shi, slo)  { dlo -= slo; dhi -= shi; if ( (unsigned long)dlo > (unsigned long)slo ) dhi--;}
-
-#ifdef __arm__
-// arm specific (should be fast on arm)
-
-#define MUL64(hi, lo, x, y) \
-    asm ("smull	%0, %1, %2, %3"  \
-	 : "=&r" (lo), "=&r" (hi)  \
-	 : "%r" (x), "r" (y))
-
-#define MULA64(hi, lo, x, y)  \
-    asm ("smlal	%0, %1, %2, %3"  \
-	 : "+r" (lo), "+r" (hi)  \
-	 : "%r" (x), "r" (y))
-
-#define SCALE64(hi, lo, bits) \
-    ({ int32_t __result;  \
-    asm ("movs	%0, %1, lsr %3\n\t"  \
-	 "adc	%0, %0, %2, lsl %4"  \
-	 : "=&r" (__result)  \
-	 : "r" (lo), "r" (hi), \
-	 "M" (bits), "M" (32 - bits)  \
-	 : "cc");  \
-    __result;  \
-    })
-
-#else
-//general purpose (slow?)
-
-#define MUL64(hi, lo, a, b) {long long x; x = (long long)a * b; hi = (long)(x >> 32); lo = (long)x;}
-#define MULA64(hi, lo, a, b)  {long long x; x = (long long)a * b; hi += (long)(x >> 32); lo += (long)x; if ((unsigned long)lo < (unsigned long)x) hi++;}
-#define SCALE64(hi, lo, bits) ((int32_t)((hi << (32 - bits)) | ((lo >> bits) & (0xFFFFFFFF >> bits))))
-
-#endif
-
-
-#endif
-
 int sbc_init(sbc_t *sbc, unsigned long flags);
 int sbc_decode(sbc_t *sbc, void *data, int count);
 int sbc_encode(sbc_t *sbc, void *data, int count);
Index: sbc/sbc_tables.h
===================================================================
RCS file: /cvsroot/bluetooth-alsa/btsco/sbc/sbc_tables.h,v
retrieving revision 1.5
diff -u -r1.5 sbc_tables.h
--- sbc/sbc_tables.h	28 Aug 2005 05:32:19 -0000	1.5
+++ sbc/sbc_tables.h	3 Sep 2005 14:57:06 -0000
@@ -25,6 +25,8 @@
 #ifndef __SBC_TABLES_H
 #define __SBC_TABLES_H
 
+#include "sbc_math.h"
+
 /* A2DP specification: Appendix B, page 69 */
 static const int sbc_offset4[4][4] = {
 	{ -1, 0, 0, 0 },
@@ -175,6 +177,34 @@
 	  -0.382683432365091,  0.555570233019606, -0.707106781186548,  0.831469612302547 }
 };
 
+#ifdef USE_FIXED
+
+#ifdef USE_FIXED32
+
+#define SP8(val) (val >> SCALE_PROTO8_TBL)
+#define SA8(val) (val >> SCALE_ANA8_TBL)
+
+#else // USE_FIXED32
+
+#define SP8(val) (val)
+#define SA8(val) (val)
+
+#endif // USE_FIXED32
+
+static const int32_t _sbc_proto_8[40] = {
+	SP8(0x02e5cd20), SP8(0x22d0c200), SP8(0x006bfe27), SP8(0x07808930), SP8(0x3f1c8800), SP8(0xf8810d70), SP8(0x002cfdc6), SP8(0x055acf28),
+	SP8(0x31f566c0), SP8(0xebfe57e0), SP8(0xff27c437), SP8(0x001485cc), SP8(0x041c6e58), SP8(0x2a7cfa80), SP8(0xe4c4a240), SP8(0xfe359e4c),
+	SP8(0x0048b1f8), SP8(0x0686ce30), SP8(0x38eec5c0), SP8(0xf2a1b9f0), SP8(0xffe8904a), SP8(0x0095698a), SP8(0x0824a480), SP8(0x443b3c00),
+	SP8(0xfd7badc8), SP8(0x00d3e2d9), SP8(0x00c183d2), SP8(0x084e1950), SP8(0x4810d800), SP8(0x017f43fe), SP8(0x01056dd8), SP8(0x00e9cb9f),
+	SP8(0x07d7d090), SP8(0x4a708980), SP8(0x0488fae8), SP8(0x0113bd20), SP8(0x0107b1a8), SP8(0x069fb3c0), SP8(0x4b3db200), SP8(0x00763f48)
+};
+
+static const int32_t _anamatrix8[8] = {
+	SA8(0x3b20d780), SA8(0x187de2a0), SA8(0x3ec52f80), SA8(0x3536cc40), SA8(0x238e7680), SA8(0x0c7c5c20), SA8(0x2d413cc0), SA8(0x40000000)
+};
+
+#else // USE_FIXED
+
 static const float _anamatrix8[8] = {
 	0.923879532511287, 0.382683432365091, 0.980785280403231, 0.831469612302547, 0.555570233019602,
 	0.195090322016128, 0.707106781186547, 1
@@ -189,14 +219,7 @@
 	1.99454557E-03, 1.78371731E-03, 1.53184105E-02, 1.45389840E-01, 8.85757525E-03, 2.10371986E-03,
 	2.01182533E-03, 1.29371807E-02, 1.46955073E-01, 9.02154483E-04
 };
-
-static const float _anamatrix4[4] = { 
-	0., 0., 0., 0.
-};
-
-static const float _sbc_proto_4[20] = {
-	0., 0., 0., 0., 0., 0., 0., 0., 0., 0.,
-        0., 0., 0., 0., 0., 0., 0., 0., 0., 0.,
-};
+#endif // USE_FIXED
 
 #endif /* __SBC_TABLES_H */
+
Index: sbc/sbc_tables_f.h
===================================================================
RCS file: /cvsroot/bluetooth-alsa/btsco/sbc/sbc_tables_f.h,v
retrieving revision 1.8
diff -u -r1.8 sbc_tables_f.h
--- sbc/sbc_tables_f.h	25 Aug 2005 23:14:50 -0000	1.8
+++ sbc/sbc_tables_f.h	3 Sep 2005 14:57:06 -0000
@@ -27,7 +27,7 @@
 { 0xf137ca20, 0xf9e08758, 0x061f78a8, 0x0ec835e0, 0x0ec835e0, 0x061f78a8, 0xf9e08758, 0xf137ca20 },
 { 0xf2b24cf0, 0x031f1708, 0x0fb14be0, 0x08e39da0, 0xf71c6260, 0xf04eb420, 0xfce0e8f8, 0x0d4db310 }
 };
-
+/*
 #define FIXED64_STAGE1 24
 static const int32_t _sbc_proto_8_f[40] = {
 0x02e5cd20, 0x22d0c200, 0x006bfe27, 0x07808930, 0x3f1c8800, 0xf8810d70, 0x002cfdc6, 0x055acf28, 
@@ -42,3 +42,4 @@
 0x3b20d780, 0x187de2a0, 0x3ec52f80, 0x3536cc40, 0x238e7680, 0x0c7c5c20, 0x2d413cc0, 0x40000000
 };
 
+*/
\ No newline at end of file
--- /dev/null	2005-09-03 18:50:56.041670456 +0200
+++ sbc/sbc_math.h	2005-08-30 23:48:25.000000000 +0200
@@ -0,0 +1,108 @@
+#ifndef __SBC_MATH_H
+#define __SBC_MATH_H
+
+#include <stdint.h>
+
+#define fabs(x) ((x) < 0 ?-(x) : (x))
+
+#ifdef USE_FIXED
+
+#ifdef USE_FIXED32
+
+#define SCALE_PROTO8_TBL 18
+#define SCALE_ANA8_TBL 20
+#define SCALE_STAGE1_BITS 14
+#define SCALE_STAGE2_BITS 18
+
+typedef int32_t sbc_fixed_t;
+
+#define SBC_FIXED_0(val) {val = 0;}
+#define DIV2(dst, src) {dst = src >> 1;}
+
+#define ADD(dst, src)  {dst += src;}
+#define SUB(dst, src)  {dst -= src;}
+#define MUL(dst, a, b) {dst = a*b;}
+#define MULA(dst, a, b)  {dst += a*b;}
+#define SCALE_STAGE1(src) (src >> SCALE_STAGE1_BITS)
+#define SCALE_STAGE2(src) (src >> SCALE_STAGE2_BITS)
+
+#else // USE_FIXED32
+
+#define SCALE_STAGE1_BITS 24
+#define SCALE_STAGE2_BITS 7
+
+struct sbc_fixed_struct{
+	int32_t hi;
+	uint32_t lo;
+};
+typedef struct sbc_fixed_struct sbc_fixed_t;
+
+#define SBC_FIXED_0(val) {val.hi = 0;val.lo = 0;}
+#define DIV2(dst, src) {dst.hi = src.hi >> 1; dst.lo = (src.lo >> 1); if (src.hi & 1) dst.lo |= 0x80000000; else dst.lo &= 0x7FFFFFFF;}
+
+#ifdef __arm__
+
+#define ADD(dst, src)  \
+    asm ("adds	%0, %0, %2\n\t"  \
+	 "adc	%1, %1, %3"	\
+	 : "+r" (dst.lo), "+r" (dst.hi)  \
+	 : "%r" (src.lo), "r" (src.hi))
+
+#define SUB(dst, src)  \
+    asm ("subs	%0, %0, %2\n\t"  \
+	 "sbc	%1, %1, %3"	\
+	 : "+r" (dst.lo), "+r" (dst.hi)  \
+	 : "%r" (src.lo), "r" (src.hi))
+
+#define MUL(dst, a, b) \
+    asm ("smull	%0, %1, %2, %3"  \
+	 : "=&r" (dst.lo), "=&r" (dst.hi)  \
+	 : "%r" (a), "r" (b))
+
+#define MULA(dst, a, b)  \
+    asm ("smlal	%0, %1, %2, %3"  \
+	 : "+r" (dst.lo), "+r" (dst.hi)  \
+	 : "%r" (a), "r" (b))
+
+#define SCALE_STAGE1(src) \
+    ({ int32_t __result;  \
+    asm ("movs	%0, %1, lsr %3\n\t"  \
+	 "adc	%0, %0, %2, lsl %4"  \
+	 : "=&r" (__result)  \
+	 : "r" (src.lo), "r" (src.hi), \
+	 "M" (SCALE_STAGE1_BITS), "M" (32 - SCALE_STAGE1_BITS)  \
+	 : "cc");  \
+    __result;  \
+    })
+
+#define SCALE_STAGE2(src) (src.hi >> SCALE_STAGE2_BITS)
+
+#else // _arm_
+
+#define ADD(dst, src)  {dst.lo += src.lo; dst.hi += src.hi; if ( dst.lo < src.lo ) dst.hi++;}
+#define SUB(dst, src)  {dst.hi -= src.hi; if ( dst.lo < src.lo ) dst.hi--; dst.lo -= src.lo;}
+#define MUL(dst, a, b) {int64_t x; x = (int64_t)a * b; dst.hi = x >> 32; dst.lo = x;}
+#define MULA(dst, a, b)  {int64_t x; x = (int64_t)a * b; dst.hi += (x >> 32); dst.lo += x; if (dst.lo < (uint32_t)x) dst.hi++;}
+#define SCALE_STAGE1(src) ((int32_t)((src.hi << (32 - SCALE_STAGE1_BITS)) | ((src.lo >> SCALE_STAGE1_BITS) & (0xFFFFFFFF >> SCALE_STAGE1_BITS))))
+#define SCALE_STAGE2(src) (src.hi >> SCALE_STAGE2_BITS)
+
+#endif // __arm__
+
+#endif // USE_FIXED32
+
+#else // USE_FIXED
+
+typedef double sbc_fixed_t;
+
+#define SBC_FIXED_0(val) {val = 0;}
+#define DIV2(dst, src) {dst = src / 2;}
+#define ADD(dst, src)  {dst += src;}
+#define SUB(dst, src)  {dst -= src;}
+#define MUL(dst, a, b) {dst = a*b;}
+#define MULA(dst, a, b)  {dst += a*b;}
+#define SCALE_STAGE1(src) (src)
+#define SCALE_STAGE2(src) (src)
+
+#endif // USE_FIXED
+
+#endif // __SBC_MATH_H

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

[Brad Midgley]

Victor

Excellent... I applied the patches.

Brad

Victor Shcherbatyuk wrote:
> Brad,
> 
> The patch includes restructured and cleaned up code for 8-subband fixed 
> point encoder (I didn't touch a2play yet). I've removed some of your 
> code (if you need it let me know), moved fixed tables to sbc_tables.h 
> (manually), merged floating and fixed point filter code. Now all the 
> math is in sbc_math.h, an option added for 32 bit fixed point, but I 
> could not make it sound any good, it is uses ~0% cpu producing sound of 
> 0 quality - looks fair, so if someone wants to experiment with it... :)
> 
> I will do 4 subband encoder too. Can not promise any dates, depends how 
> easy it goes...
> 
> I've played with Philips codec and I've noticed one thing. With the same 
> value of bitpool our codec produces bitrate half of what the Philips 
> codec does... So, if I set bitpool 15 for the Philips codec it will 
> produce the same bitrate and sound quality as our encoder produces with 
> bitpool eq. 32 - something might be wrong with bitallocation?
> 
> Regards,
>      Victor.
> 
> P.S. There is no real need in rmagnitude() as we can test the filter 
> code for overflowing using an test app, supplying all kind of inputs and 
> comparing its output with that of the floating point filer. I've done it 
> and currently it does not overflow, later if we need more precision? we 
> can tweak SCALE_STAGE1 and SCALE_STAGE2 to get maximum of precision 
> without overflowing....


-------------------------------------------------------
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

[Bluez-devel] bcm2035

[Oliver Ruiz Dorantes]

Hello all,

Anybody tested the chip 2035 under BlueZ stack?

I have been playing with it with good results, but suddently i get the 
BD_ADDR as 00:00:00:00:00:00, and the dongle due to this (i think) is not 
working even in windows. All other commands or inquiry process is working

Looks like it forgot its BD_ADDR, and as far as i know there is no SW 
way(hci command) to set it again, I wonder if there is a SW way that i could 
have deleted it by mistake....

The model is BT3035 from Tecom with as i said the chip is Broadcom 2035

Any idea / advice ?

thanks 


		
______________________________________________ 
Renovamos el Correo Yahoo! 
Nuevos servicios, más seguridad 
http://correo.yahoo.es



-------------------------------------------------------
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

Re: [Bluez-devel] bcm2035

[Paul Webster]

> Anybody tested the chip 2035 under BlueZ stack?
I have a laptop sporting one of these USB based chips "built-in". An
HP Pavilion zd8004AP

> I have been playing with it with good results, but suddently i get the
> BD_ADDR as 00:00:00:00:00:00, and the dongle due to this (i think) is not
> working even in windows. All other commands or inquiry process is working
Same, although, when I first purchased the laptop, it came with
Windows XP installed, and the bluetooth _WAS_ working. After
repartitioning the 80Gb HDD and re-installing XP on a smaller
partition, using the discs that came with the laptop, I couldn't get
bluetooth installed again. I kept getting errors saying that the
bluetooth license was not valid, and asking to locate the correct
license file.

Under linux, it works fine, although I have to specify the interface
(hci0) every time I use things like hcitool and hciconfig. For
example:

~ $ hciconfig
hci0:   Type: USB
        BD Address: 00:00:00:00:00:00 ACL MTU: 377:10 SCO MTU: 16:0
        UP RUNNING PSCAN ISCAN=20
        RX bytes:111 acl:0 sco:0 events:14 errors:0
        TX bytes:310 acl:0 sco:0 commands:14 errors:0
~ $ hcitool scan
Device is not available: No such device
~ $ hcitool -i hci0 scan
Scanning ...
        00:0A:94:C0:2A:6E       Bluetooth Mouse
~ $ hidd --connect 00:0A:94:C0:2A:6E
~ $ hidd --show                    =20
00:0A:94:C0:2A:6E HID Boot Device [0000:0000] connected [boot-protocol]

> Looks like it forgot its BD_ADDR, and as far as i know there is no SW
> way(hci command) to set it again, I wonder if there is a SW way that i co=
uld
> have deleted it by mistake....
This is kind of an interesting idea. I would have assumed that the
BD_ADDR was a harware adress, and not alterable by software.
Certainly, what I assume was/is the original adress is stamped on a
sticker on the module (I pulled the laptop appart to check it out last
week).

> The model is BT3035 from Tecom with as i said the chip is Broadcom 2035
for reference:
~ $ lsusb
...
Bus 002 Device 002: ID 0a5c:2035 Broadcom Corp. BCM2035 Bluetooth
...

The lable on the module says:
Broadcom BCM92035NMD
FCC ID: QDS-BRCM1009
Canada IC: 4324A-BRCM1009
HP PN: 36438-001
Product of Taiwan
F/W: 105.97 Rev:0A
SPS PN: 376651-001

> Any idea / advice ?
I'm planning on looking into it some more once I have some more time


-------------------------------------------------------
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

Re: [Bluez-devel] bcm2035

[Oliver Ruiz Dorantes]

Paul,

> bluetooth installed again. I kept getting errors saying that the
> bluetooth license was not valid, and asking to locate the correct
> license file.

Same on mine in different computers, I think in this license file there
could be at least a BD_ADDR wich matches the Broadcom assigned values, and
as it is reported as 00:00:00:00:00:00 causes the mismatch.

~ $ hidd --show
> 00:0A:94:C0:2A:6E HID Boot Device [0000:0000] connected [boot-protocol]

As I can see this is the BD_ADDR of the keyboard, but were you able to get a
valid BD_ADDR of your built-in device? in other words, can another devices
look for you / connect to you?

> This is kind of an interesting idea. I would have assumed that the
> BD_ADDR was a harware adress, and not alterable by software.

Me also, I have seen looking for, and i found sources (setbd-bluez.c) than
can set the BD_ADDR of a "Ericsson ROK 101" issuing 2 HCI commands in the 
ogf 0x3f which is out of the specifications:

HCI Command: ogf 0x3f, ocf 0x000d, plen 6
HCI Command: ogf 0x3f, ocf 0x0022, plen 0

So here it looks like there is a "hide way" at least for this Ericsson 
device.

Can I keep hope that Broadcom left this possibility as well, and start to 
cast commands in the 0x3f  range?

thanks for any related comment about..

Oliver 


		
______________________________________________ 
Renovamos el Correo Yahoo! 
Nuevos servicios, más seguridad 
http://correo.yahoo.es



-------------------------------------------------------
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

Re: [Bluez-devel] bcm2035

[Paul Webster]

On 9/5/05, Oliver Ruiz Dorantes <urnenfel@tiscali.es> wrote:
> Paul,
>=20
> > bluetooth installed again. I kept getting errors saying that the
> > bluetooth license was not valid, and asking to locate the correct
> > license file.
>=20
> Same on mine in different computers, I think in this license file there
> could be at least a BD_ADDR wich matches the Broadcom assigned values, an=
d
> as it is reported as 00:00:00:00:00:00 causes the mismatch.
Hmmm, I think it's about time I lodged a support issue with my laptop
manufacturer and see what they come up with, at least with regards to
fixing the Windows side of things. That may shed light on the monster
we're dealing with here.

> > ~ $ hidd --show
> > 00:0A:94:C0:2A:6E HID Boot Device [0000:0000] connected [boot-protocol]
>=20
> As I can see this is the BD_ADDR of the keyboard, but were you able to ge=
t a
> valid BD_ADDR of your built-in device? in other words, can another device=
s
> look for you / connect to you?

Yeah, that was just to show that it's operational one way. I made a
half-hearted attempt to connect my bluetooth mobile without success
when I first got bluez up, but it was late, so I gave up and didn't
try again. I'll give it a go next time I try things with bluez

> > This is kind of an interesting idea. I would have assumed that the
> > BD_ADDR was a harware adress, and not alterable by software.
>=20
> Me also, I have seen looking for, and i found sources (setbd-bluez.c) tha=
n
> can set the BD_ADDR of a "Ericsson ROK 101" issuing 2 HCI commands in the
> ogf 0x3f which is out of the specifications:
>=20
> HCI Command: ogf 0x3f, ocf 0x000d, plen 6
> HCI Command: ogf 0x3f, ocf 0x0022, plen 0
>=20
> So here it looks like there is a "hide way" at least for this Ericsson
> device.
>=20
> Can I keep hope that Broadcom left this possibility as well, and start to
> cast commands in the 0x3f  range?

This looks like they're setting a BD_ADDR of a remote device over a
bluetooth connection, not the local one. Trawling other links on the
digitalmunition website hosting the file you referenced found
references to the license.dat issue. More trawling to be done outside
of work hours :)


-------------------------------------------------------
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

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

[Victor Shcherbatyuk]

Brad,

I've checked in code for 4-subbands encoder. I've tried it only on x86, but 
I do not expect any surprises on arm.

It turned out (probably I should read the specs more carefully) that 
4-subbands with the same bitpool are actually superior to 8-subbands in 
sound quality, producing 2 times higher bitrate and taking more time to 
encode... (well if I look at the spec, the same bitpool is distributed over 
4 subbands or over 8 subbands -> 4 subbands have 2 times higher bitrate with 
the same bitpool...) I've tried this with Philips codec (there was a 
reference to it somewhere on the web) and our results look consistent...

I've added the options to specify the number of subbands and use of joint 
stereo to sbcenc.

Things to do (I'll spend some time on it):
1. Check if joint stereo works
2. Add command line arguments for bitpool, subbands, joint stereo, other? 
(thrifty flag is a bit obscure)
3. Check bit allocation (there is a difference still with the Philips codec)
4. Check/tune the error introduced by fixed point conversion (this can be 
done comparing to old floating point implementation, cause current is using 
int32_t for subbands, which might introduce some error in the output stream)
5. There are still some optimizations regarding memcopies....

Well, it will take some time.

Regards,
      Victor.

P.S. 32-bit fixed point probably is not working, straight forward 
implementation will not work (as it is now) unless some tricks are used...

----- Original Message ----- 
From: "Brad Midgley" <bmidgley@xmission.com>
To: <bluez-devel@lists.sourceforge.net>
Sent: Saturday, September 03, 2005 18:05
Subject: Re: [Bluez-devel] sbc and fixed-point progress


> Victor
>
> Excellent... I applied the patches.
>
> Brad
>
> Victor Shcherbatyuk wrote:
>> Brad,
>>
>> The patch includes restructured and cleaned up code for 8-subband fixed 
>> point encoder (I didn't touch a2play yet). I've removed some of your code 
>> (if you need it let me know), moved fixed tables to sbc_tables.h 
>> (manually), merged floating and fixed point filter code. Now all the math 
>> is in sbc_math.h, an option added for 32 bit fixed point, but I could not 
>> make it sound any good, it is uses ~0% cpu producing sound of 0 quality - 
>> looks fair, so if someone wants to experiment with it... :)
>>
>> I will do 4 subband encoder too. Can not promise any dates, depends how 
>> easy it goes...
>>
>> I've played with Philips codec and I've noticed one thing. With the same 
>> value of bitpool our codec produces bitrate half of what the Philips 
>> codec does... So, if I set bitpool 15 for the Philips codec it will 
>> produce the same bitrate and sound quality as our encoder produces with 
>> bitpool eq. 32 - something might be wrong with bitallocation?
>>
>> Regards,
>>      Victor.
>>
>> P.S. There is no real need in rmagnitude() as we can test the filter code 
>> for overflowing using an test app, supplying all kind of inputs and 
>> comparing its output with that of the floating point filer. I've done it 
>> and currently it does not overflow, later if we need more precision? we 
>> can tweak SCALE_STAGE1 and SCALE_STAGE2 to get maximum of precision 
>> without overflowing....
>
>
> -------------------------------------------------------
> 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

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

[Brad Midgley]

Victor

> I've checked in code for 4-subbands encoder. I've tried it only on x86, 
> but I do not expect any surprises on arm.

Again, this is very cool...

> It turned out (probably I should read the specs more carefully) that 
> 4-subbands with the same bitpool are actually superior to 8-subbands in 
> sound quality, producing 2 times higher bitrate

wow, I hadn't understood that. I always thought 4 subbands sounded 
better just because my stereo headset is the sort of tinny in-the-ear 
type and I figured 4 subbands was truncating high-end frequencies just 
enough to make the sound less shrill.

> I've added the options to specify the number of subbands and use of 
> joint stereo to sbcenc.

ok, good.

> Things to do (I'll spend some time on it):
> 1. Check if joint stereo works
> 2. Add command line arguments for bitpool, subbands, joint stereo, 
> other? (thrifty flag is a bit obscure)

yes, "thrifty" was a quick hack

> 4. Check/tune the error introduced by fixed point conversion (this can 
> be done comparing to old floating point implementation, cause current is 
> using int32_t for subbands, which might introduce some error in the 
> output stream)

how is 32 bit maths selected? I assume we have to tweak the source to 
try it...

> 5. There are still some optimizations regarding memcopies....

yes... I've been struggling with this in the decoder...

Brad


-------------------------------------------------------
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

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

[Victor Shcherbatyuk]

To select 32-bit need to define USE_FIXED32 along with USE_FIXED, I hope
it compiles this way, otherwise minor changes needed (it was compiling
before my last change). Scaling for STAGE1 and STAGE2 should be updated
in sbc_math.h in 32-bit section.
Btw, it took around 1 hour to do 4-subbands cause I managed to
"automate" it so it generates the code and the tables in one run of the
filter, but it might be no applicable to decoder, I'll send you the code
anyway :)

Regards,
      Victor.
=20

-----Original Message-----
From: bluez-devel-admin@lists.sourceforge.net
[mailto:bluez-devel-admin@lists.sourceforge.net] On Behalf Of Brad
Midgley
Sent: Wednesday, September 07, 2005 5:24 AM
To: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] sbc and fixed-point progress

Victor

> I've checked in code for 4-subbands encoder. I've tried it only on=20
> x86, but I do not expect any surprises on arm.

Again, this is very cool...

> It turned out (probably I should read the specs more carefully) that=20
> 4-subbands with the same bitpool are actually superior to 8-subbands=20
> in sound quality, producing 2 times higher bitrate

wow, I hadn't understood that. I always thought 4 subbands sounded
better just because my stereo headset is the sort of tinny in-the-ear
type and I figured 4 subbands was truncating high-end frequencies just
enough to make the sound less shrill.

> I've added the options to specify the number of subbands and use of=20
> joint stereo to sbcenc.

ok, good.

> Things to do (I'll spend some time on it):
> 1. Check if joint stereo works
> 2. Add command line arguments for bitpool, subbands, joint stereo,=20
> other? (thrifty flag is a bit obscure)

yes, "thrifty" was a quick hack

> 4. Check/tune the error introduced by fixed point conversion (this can

> be done comparing to old floating point implementation, cause current=20
> is using int32_t for subbands, which might introduce some error in the

> output stream)

how is 32 bit maths selected? I assume we have to tweak the source to
try it...

> 5. There are still some optimizations regarding memcopies....

yes... I've been struggling with this in the decoder...

Brad


-------------------------------------------------------
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


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 immediatel=
y and delete or destroy this e-mail message and any attachment(s), withou=
t copying, saving, forwarding, disclosing or using its contents in any ot=
her way. TomTom N.V., TomTom International BV or any other company belong=
ing to the TomTom group of companies will not be liable for damage relati=
ng to the communication by e-mail of data, documents or any other informa=
tion.


-------------------------------------------------------
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

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

[Victor Shcherbatyuk]

Brad,

Some more explanations to what was done up till now (so that I'm not the
only one who undestands it, I hope I''m not).

Encoder analysis filter consists of 2 multiply/accumulate parts, at
first, blocks (total of 8) of the incoming 16-bit audio samples are
multiplied with sbc_proto[] array and accumulated in t[] array, then
elements of t[] array are multiplied with anamatrix[] array and
accumulated in out[] array forming subband samples.

Now, to convert it to fixed point it was decided to use 64-bit result (2
32-bit variables) to hold the result of multiplication (result of
multiplication of N bit number by M bit number requires NxM result bits
to prevent overflowing).
All the table were scaled (multiplied by 2 ^ X) to fit 32 bit precisely
- that is to have maximum precision that fits into 32-bit variable.
Now, for the first multiply-accumulate stage, 16-bit pcm samples are
multiplied by 32-bit table values giving 48-bit result, there are up to
10 accumulates, which would require additional 4 bits on top of 48 to
keep the result, giving 52 bit. The result will be multiplied by
anamatrix[] at the second multiply-accumulate stage, and as we can only
multiply 32-bit numbers, 52 bits should be scaled down to 32 giving 20
as a scale constant. Now, multiplying 32-bit t[] value by 32-bit
anamatrix[] value, at the second stage,  would give 64 bits as result,
but we also have up to 10 accumulates that require additional 4 bits to
keep the result, so that the result of first multiply-accumulate stage
should be scaled not by 20, but 24 bits to give some room for
accumulates of the second stage- this gives 24 as a scale constant
(which is defined SCALEX_STAGE1).
The result of the second stage should be scaled down to restore normal
scaling. E.g., values of the sbc_proto[] were multiplied by 2^33 to fit
precisely 32-bit, then to get intermediate t[] values, output of first
stage was shilted 24-bit (equals dividing by 2^24), then values of
anamatrix[] were multiplied by 2^30 to fit 32-bit, so the result of the
second stage is 
2^33 * 2^30 / 2^24 = 2^39 "above" normal scale -> it should be scaled
down 39 bits -> by leaving out lower 32-bit and assigning to subband
sample output values higher 32-bit part of the second stage result
scaled down 7 bits (SCALEX_STAGE2) we restore the normal scale.

For the 32bit fixed point reasoning is the same, except that tables
values scaled down to fit 16 bit (or less) to preven oveflowing when
multiplied with 16 bit pcm samples.

Hope it makes it a bit clear... If not I should write a loger story :)

Regards,
     Victor.

On Wed, 2005-09-07 at 09:14 +0200, Victor Shcherbatyuk wrote:
> To select 32-bit need to define USE_FIXED32 along with USE_FIXED, I hope
> it compiles this way, otherwise minor changes needed (it was compiling
> before my last change). Scaling for STAGE1 and STAGE2 should be updated
> in sbc_math.h in 32-bit section.
> Btw, it took around 1 hour to do 4-subbands cause I managed to
> "automate" it so it generates the code and the tables in one run of the
> filter, but it might be no applicable to decoder, I'll send you the code
> anyway :)
> 
> Regards,
>       Victor.
>  
> 
> -----Original Message-----
> From: bluez-devel-admin@lists.sourceforge.net
> [mailto:bluez-devel-admin@lists.sourceforge.net] On Behalf Of Brad
> Midgley
> Sent: Wednesday, September 07, 2005 5:24 AM
> To: bluez-devel@lists.sourceforge.net
> Subject: Re: [Bluez-devel] sbc and fixed-point progress
> 
> Victor
> 
> > I've checked in code for 4-subbands encoder. I've tried it only on 
> > x86, but I do not expect any surprises on arm.
> 
> Again, this is very cool...
> 
> > It turned out (probably I should read the specs more carefully) that 
> > 4-subbands with the same bitpool are actually superior to 8-subbands 
> > in sound quality, producing 2 times higher bitrate
> 
> wow, I hadn't understood that. I always thought 4 subbands sounded
> better just because my stereo headset is the sort of tinny in-the-ear
> type and I figured 4 subbands was truncating high-end frequencies just
> enough to make the sound less shrill.
> 
> > I've added the options to specify the number of subbands and use of 
> > joint stereo to sbcenc.
> 
> ok, good.
> 
> > Things to do (I'll spend some time on it):
> > 1. Check if joint stereo works
> > 2. Add command line arguments for bitpool, subbands, joint stereo, 
> > other? (thrifty flag is a bit obscure)
> 
> yes, "thrifty" was a quick hack
> 
> > 4. Check/tune the error introduced by fixed point conversion (this can
> 
> > be done comparing to old floating point implementation, cause current 
> > is using int32_t for subbands, which might introduce some error in the
> 
> > output stream)
> 
> how is 32 bit maths selected? I assume we have to tweak the source to
> try it...
> 
> > 5. There are still some optimizations regarding memcopies....
> 
> yes... I've been struggling with this in the decoder...
> 
> Brad
> 
> 
> -------------------------------------------------------
> 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
> 
> 
> 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