* [Bluez-devel] libsbc optimizing
@ 2005-05-18 23:31 Brad Midgley
2005-05-20 22:04 ` Henryk Plötz
0 siblings, 1 reply; 7+ messages in thread
From: Brad Midgley @ 2005-05-18 23:31 UTC (permalink / raw)
To: BlueZ Mailing List
[-- Attachment #1: Type: text/plain, Size: 827 bytes --]
Hi,
I have been looking at the problem of libsbc performance on arm. My
first pass is on the decoder. I'm trying to cut down deeply nested fp
multiply/divide ops.
I originally planned regression tests in the build process for
performance/correctness but decided against them:
- performance may actually go down on x86 where I build when we reduce
fp usage
- the character of roundoff errors will change and the lossy stream
will probably look different even when it is still "correct"
Anyway, I will need to know the range of certain values in order to make
much progress. I tried hunting down how they are calculated but it gets
difficult very quickly.
Can I get help with the ranges for bits[ch][sb] in sbc_unpack_frame and
the state.* vectors if they're bounded?
How about this first little patch?
Brad
[-- Attachment #2: opt1.patch --]
[-- Type: text/plain, Size: 1884 bytes --]
Index: sbc/sbc.c
===================================================================
RCS file: /cvsroot/bluetooth-alsa/btsco/sbc/sbc.c,v
retrieving revision 1.33
diff -u -b -B -w -p -r1.33 sbc.c
--- sbc/sbc.c 17 May 2005 06:48:02 -0000 1.33
+++ sbc/sbc.c 18 May 2005 22:32:13 -0000
@@ -391,7 +391,6 @@ static int sbc_unpack_frame(const u_int8
int bits[2][8]; /* bits distribution */
int levels[2][8]; /* levels derived from that */
- double scalefactor[2][8]; /* derived from frame->scale_factors */
if (len < 4)
return -1;
@@ -525,7 +524,6 @@ static int sbc_unpack_frame(const u_int8
for (ch = 0; ch < frame->channels; ch++) {
for (sb = 0; sb < frame->subbands; sb++) {
levels[ch][sb] = (1 << bits[ch][sb]) - 1;
- scalefactor[ch][sb] = 2 << frame->scale_factor[ch][sb];
}
}
@@ -534,8 +532,8 @@ static int sbc_unpack_frame(const u_int8
for (sb = 0; sb < frame->subbands; sb++) {
if (levels[ch][sb] > 0) {
frame->sb_sample[blk][ch][sb] =
- scalefactor[ch][sb] * ((frame->audio_sample[blk][ch][sb] * 2.0 + 1.0) /
- levels[ch][sb] - 1.0);
+ (((frame->audio_sample[blk][ch][sb] << 1) | 1) << frame->scale_factor[ch][sb])/(float)levels[ch][sb]
+ - (1 << frame->scale_factor[ch][sb]);
} else {
frame->sb_sample[blk][ch][sb] = 0;
}
@@ -547,10 +545,11 @@ static int sbc_unpack_frame(const u_int8
for (blk = 0; blk < frame->blocks; blk++) {
for (sb = 0; sb < frame->subbands; sb++) {
if (frame->join & (0x01 << sb)) {
- frame->sb_sample[blk][0][sb] =
+ double temp =
frame->sb_sample[blk][0][sb] + frame->sb_sample[blk][1][sb];
frame->sb_sample[blk][1][sb] =
- frame->sb_sample[blk][0][sb] - 2 * frame->sb_sample[blk][1][sb];
+ frame->sb_sample[blk][0][sb] - frame->sb_sample[blk][1][sb];
+ frame->sb_sample[blk][0][sb] = temp;
}
}
}
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [Bluez-devel] libsbc optimizing
2005-05-18 23:31 [Bluez-devel] libsbc optimizing Brad Midgley
@ 2005-05-20 22:04 ` Henryk Plötz
2005-05-21 0:14 ` Brad Midgley
0 siblings, 1 reply; 7+ messages in thread
From: Henryk Plötz @ 2005-05-20 22:04 UTC (permalink / raw)
To: bluez-devel
[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]
Moin,
Am Wed, 18 May 2005 17:31:10 -0600 schrieb Brad Midgley:
> Can I get help with the ranges for bits[ch][sb] in sbc_unpack_frame
> and the state.* vectors if they're bounded?
>
> How about this first little patch?
This doesn't particularly aid readability so I'd suggest to keep the old
code in a comment to explain what it should do. Apart from that it looks
fine and you're doing some clever things. So if it improves performance,
go ahead.
I thought about it: Do you have long integers on that platform or will
they be slow too? Basically there should be no number greater than 2^16
anywhere (I'll have to check that, though) and we only need add,
multiply and shift.
A naive fixed point implementation would be to use a 32 bit integers and
shift the original value left 16 bits (multiplying by 2^16) leaving 16
bits before and 16 bits after the decimal point. Add and Shift will work
as usual, but for multiply additional 16 bits (e.g. an integer type with
at least 48 bits) are needed.
--
Henryk Plötz
Grüße aus Berlin
~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~
~ Help Microsoft fight software piracy: Give Linux to a friend today! ~
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bluez-devel] libsbc optimizing
2005-05-20 22:04 ` Henryk Plötz
@ 2005-05-21 0:14 ` Brad Midgley
2005-05-21 0:28 ` Brad Midgley
0 siblings, 1 reply; 7+ messages in thread
From: Brad Midgley @ 2005-05-21 0:14 UTC (permalink / raw)
To: bluez-devel
Henryk
> This doesn't particularly aid readability so I'd suggest to keep the old
> code in a comment
ok
> I thought about it: Do you have long integers on that platform or will
> they be slow too? Basically there should be no number greater than 2^16
> anywhere (I'll have to check that, though) and we only need add,
> multiply and shift.
32-bit ints are not costly, but >32 probably are too expensive.
> A naive fixed point implementation would be to use a 32 bit integers and
> shift the original value left 16 bits (multiplying by 2^16) leaving 16
> bits before and 16 bits after the decimal point. Add and Shift will work
> as usual, but for multiply additional 16 bits (e.g. an integer type with
> at least 48 bits) are needed.
uclibc provides an fp emulation library that is already doing a naive
implementation. On a 400mhz pxa255, it works (sort of) for a2dp sink but
only if encoding parameters are set low. It doesn't work for a2dp
source--it only produces some choppy audio and then drops out completely.
maybe we just need to break floats into two ints. using rationals
(numerator/denominator) is what i was thinking when I saw that first fp
division by bits[][].
Brad
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bluez-devel] libsbc optimizing
2005-05-21 0:14 ` Brad Midgley
@ 2005-05-21 0:28 ` Brad Midgley
2005-05-24 16:55 ` Brad Midgley
0 siblings, 1 reply; 7+ messages in thread
From: Brad Midgley @ 2005-05-21 0:28 UTC (permalink / raw)
To: bluez-devel
hey
> maybe we just need to break floats into two ints. using rationals
> (numerator/denominator) is what i was thinking when I saw that first fp
> division by bits[][].
i'm liking this better as i think about it. the precomputed arrays would
be changed into rationals too.
one tricky bit will be how and when to normalize the ratio.
brad
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bluez-devel] libsbc optimizing
2005-05-21 0:28 ` Brad Midgley
@ 2005-05-24 16:55 ` Brad Midgley
2005-05-24 17:10 ` Marcel Holtmann
0 siblings, 1 reply; 7+ messages in thread
From: Brad Midgley @ 2005-05-24 16:55 UTC (permalink / raw)
To: bluez-devel
guys
it's a little bit strange talking about math libraries here :)
i am going to try using gnu mp. it provides rationals and short floats.
i will make it an autoconf option so we keep the regular floating point
implementation in case that's what you want.
brad
Brad Midgley wrote:
> hey
>
>> maybe we just need to break floats into two ints. using rationals
>> (numerator/denominator) is what i was thinking when I saw that first
>> fp division by bits[][].
>
>
> i'm liking this better as i think about it. the precomputed arrays would
> be changed into rationals too.
>
> one tricky bit will be how and when to normalize the ratio.
>
> brad
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bluez-devel] libsbc optimizing
2005-05-24 16:55 ` Brad Midgley
@ 2005-05-24 17:10 ` Marcel Holtmann
2005-05-24 17:59 ` Brad Midgley
0 siblings, 1 reply; 7+ messages in thread
From: Marcel Holtmann @ 2005-05-24 17:10 UTC (permalink / raw)
To: bluez-devel
Hi Brad,
> it's a little bit strange talking about math libraries here :)
>
> i am going to try using gnu mp. it provides rationals and short floats.
> i will make it an autoconf option so we keep the regular floating point
> implementation in case that's what you want.
go ahead, but maybe I repeat myself; we need an integer version of the
SBC codec. This is where we should head with any optimization. However I
am the wrong person for this stuff, but I would welcome everyone who
wants to work on it.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bluez-devel] libsbc optimizing
2005-05-24 17:10 ` Marcel Holtmann
@ 2005-05-24 17:59 ` Brad Midgley
0 siblings, 0 replies; 7+ messages in thread
From: Brad Midgley @ 2005-05-24 17:59 UTC (permalink / raw)
To: bluez-devel
fwiw,
i think this gives us what you're asking for (indirectly). gnu mp has
hand-optimized assembly backends for a few platforms, including arm. it
falls back to plain int math for platforms with no targeted assembly.
brad
Marcel Holtmann wrote:
> Hi Brad,
>
>
>>it's a little bit strange talking about math libraries here :)
>>
>>i am going to try using gnu mp. it provides rationals and short floats.
>>i will make it an autoconf option so we keep the regular floating point
>>implementation in case that's what you want.
>
>
> go ahead, but maybe I repeat myself; we need an integer version of the
> SBC codec. This is where we should head with any optimization. However I
> am the wrong person for this stuff, but I would welcome everyone who
> wants to work on it.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2005-05-24 17:59 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-05-18 23:31 [Bluez-devel] libsbc optimizing Brad Midgley
2005-05-20 22:04 ` Henryk Plötz
2005-05-21 0:14 ` Brad Midgley
2005-05-21 0:28 ` Brad Midgley
2005-05-24 16:55 ` Brad Midgley
2005-05-24 17:10 ` Marcel Holtmann
2005-05-24 17:59 ` Brad Midgley
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.