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

Victor Shcherbatyuk
2005-08-28T22:26:02Z

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