linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* RE: [Bluez-devel] sbc and fixed-point progress
@ 2005-08-24 12:18 Victor Shcherbatyuk
  2005-08-24 16:40 ` Brad Midgley
  2005-08-26  5:10 ` Brad Midgley
  0 siblings, 2 replies; 36+ messages in thread
From: Victor Shcherbatyuk @ 2005-08-24 12:18 UTC (permalink / raw)
  To: bluez-devel

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

^ permalink raw reply	[flat|nested] 36+ messages in thread
* RE: [Bluez-devel] sbc and fixed-point progress
@ 2005-09-07  7:14 Victor Shcherbatyuk
  2005-09-07 21:18 ` Victor Shcherbatyuk
  0 siblings, 1 reply; 36+ messages in thread
From: Victor Shcherbatyuk @ 2005-09-07  7:14 UTC (permalink / raw)
  To: bluez-devel

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

^ permalink raw reply	[flat|nested] 36+ messages in thread
* RE: [Bluez-devel] sbc and fixed-point progress
@ 2005-08-26  8:07 Victor Shcherbatyuk
  0 siblings, 0 replies; 36+ messages in thread
From: Victor Shcherbatyuk @ 2005-08-26  8:07 UTC (permalink / raw)
  To: bluez-devel

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

^ permalink raw reply	[flat|nested] 36+ messages in thread
* RE: [Bluez-devel] sbc and fixed-point progress
@ 2005-08-26  8:02 Victor Shcherbatyuk
  2005-08-27  3:01 ` Brad Midgley
  0 siblings, 1 reply; 36+ messages in thread
From: Victor Shcherbatyuk @ 2005-08-26  8:02 UTC (permalink / raw)
  To: bluez-devel

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

^ permalink raw reply	[flat|nested] 36+ messages in thread
* RE: [Bluez-devel] sbc and fixed-point progress
@ 2005-08-23 15:00 Victor Shcherbatyuk
  0 siblings, 0 replies; 36+ messages in thread
From: Victor Shcherbatyuk @ 2005-08-23 15:00 UTC (permalink / raw)
  To: bluez-devel

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

^ permalink raw reply	[flat|nested] 36+ messages in thread
* RE: [Bluez-devel] sbc and fixed-point progress
@ 2005-08-01  8:20 Victor Shcherbatyuk
  2005-08-01  8:41 ` Brad Midgley
  0 siblings, 1 reply; 36+ messages in thread
From: Victor Shcherbatyuk @ 2005-08-01  8:20 UTC (permalink / raw)
  To: bluez-devel

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

^ permalink raw reply	[flat|nested] 36+ messages in thread
* RE: [Bluez-devel] sbc and fixed-point progress
@ 2005-07-28 13:14 Victor Shcherbatyuk
  2005-07-28 14:59 ` Brad Midgley
  2005-09-03 15:33 ` Victor Shcherbatyuk
  0 siblings, 2 replies; 36+ messages in thread
From: Victor Shcherbatyuk @ 2005-07-28 13:14 UTC (permalink / raw)
  To: bluez-devel

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

^ permalink raw reply	[flat|nested] 36+ messages in thread
* [Bluez-devel] sbc and fixed-point progress
@ 2005-07-04  4:03 Brad Midgley
  2005-07-04 11:11 ` Marcel Holtmann
  0 siblings, 1 reply; 36+ messages in thread
From: Brad Midgley @ 2005-07-04  4:03 UTC (permalink / raw)
  To: BlueZ Mailing List

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

^ permalink raw reply	[flat|nested] 36+ messages in thread
end of thread, other threads:[~2005-09-07 21:18 UTC | newest]

Thread overview: 36+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-08-24 12:18 [Bluez-devel] sbc and fixed-point progress Victor Shcherbatyuk
2005-08-24 16:40 ` Brad Midgley
2005-08-24 21:06   ` Victor Shcherbatyuk
2005-08-26  5:10 ` Brad Midgley
2005-08-27 22:54   ` Victor Shcherbatyuk
2005-08-28  5:44     ` Brad Midgley
2005-08-28 22:26       ` Victor Shcherbatyuk
2005-08-23 20:42         ` Roberto
2005-08-29 17:08           ` Brad Midgley
2005-08-23 21:10             ` Roberto
2005-08-29 20:18               ` Brad Midgley
2005-08-29 21:04                 ` Roberto
  -- strict thread matches above, loose matches on Subject: below --
2005-09-07  7:14 Victor Shcherbatyuk
2005-09-07 21:18 ` Victor Shcherbatyuk
2005-08-26  8:07 Victor Shcherbatyuk
2005-08-26  8:02 Victor Shcherbatyuk
2005-08-27  3:01 ` Brad Midgley
2005-08-23 15:00 Victor Shcherbatyuk
2005-08-01  8:20 Victor Shcherbatyuk
2005-08-01  8:41 ` Brad Midgley
2005-07-28 13:14 Victor Shcherbatyuk
2005-07-28 14:59 ` Brad Midgley
2005-07-28 18:41   ` Victor Shcherbatyuk
2005-07-28 19:21     ` Victor Shcherbatyuk
2005-07-28 21:09       ` Brad Midgley
2005-08-21 18:47   ` Victor Shcherbatyuk
2005-08-21 21:56     ` Roberto
2005-08-21 22:24       ` Victor Shcherbatyuk
2005-08-22  6:15     ` Brad Midgley
2005-08-22  7:22       ` Brad Midgley
2005-09-03 15:33 ` Victor Shcherbatyuk
2005-09-03 16:05   ` Brad Midgley
2005-09-06 21:53     ` Victor Shcherbatyuk
2005-09-07  3:24       ` Brad Midgley
2005-07-04  4:03 Brad Midgley
2005-07-04 11:11 ` Marcel Holtmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).