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

Brad Midgley
2005-08-28T05:44:28Z

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