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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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" <[email protected]>
To: <[email protected]>
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" <[email protected]>
> > To: <[email protected]>
> > 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" <[email protected]>
> >>>To: <[email protected]>
> >>>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" <[email protected]>
> >>>>To: <[email protected]>
> >>>>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"
> >>>
> >>><[email protected]>
> >>>
> >>>>>>To: <[email protected]>
> >>>>>>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: [email protected] on behalf of Victor
> >>>>>>>>Shcherbatyuk
> >>>>>>>>Sent: Tue 8/23/2005 5:00 PM
> >>>>>>>>To: [email protected]
> >>>>>>>>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: [email protected] on behalf of Brad
> >>>
> >>>Midgley
> >>>
> >>>
> >>>>>>>>Sent: Mon 8/22/2005 9:22 AM
> >>>>>>>>To: [email protected]
> >>>>>>>>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
> >>>>>>>>[email protected]
> >>>>>>>>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
> >>>>>>>[email protected]
> >>>>>>>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
> >>>>>[email protected]
> >>>>>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
> >>>>[email protected]
> >>>>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
> >>>[email protected]
> >>>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
> >>[email protected]
> >>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
> > [email protected]
> > 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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" <[email protected]>
> To: <[email protected]>
> 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" <[email protected]>
>>>To: <[email protected]>
>>>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" <[email protected]>
>>>>To: <[email protected]>
>>>>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"
>>>
>>><[email protected]>
>>>
>>>>>>To: <[email protected]>
>>>>>>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: [email protected] on behalf of Victor
>>>>>>>>Shcherbatyuk
>>>>>>>>Sent: Tue 8/23/2005 5:00 PM
>>>>>>>>To: [email protected]
>>>>>>>>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: [email protected] on behalf of Brad
>>>
>>>Midgley
>>>
>>>
>>>>>>>>Sent: Mon 8/22/2005 9:22 AM
>>>>>>>>To: [email protected]
>>>>>>>>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
>>>>>>>>[email protected]
>>>>>>>>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
>>>>>>>[email protected]
>>>>>>>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
>>>>>[email protected]
>>>>>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
>>>>[email protected]
>>>>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
>>>[email protected]
>>>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
>>[email protected]
>>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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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" <[email protected]>
To: <[email protected]>
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" <[email protected]>
> > To: <[email protected]>
> > 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" <[email protected]>
> >>To: <[email protected]>
> >>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"
> >
> > <[email protected]>
> >
> >>>>To: <[email protected]>
> >>>>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: [email protected] on behalf of Victor
> >>>>>>Shcherbatyuk
> >>>>>>Sent: Tue 8/23/2005 5:00 PM
> >>>>>>To: [email protected]
> >>>>>>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: [email protected] on behalf of Brad
> >
> > Midgley
> >
> >>>>>>Sent: Mon 8/22/2005 9:22 AM
> >>>>>>To: [email protected]
> >>>>>>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
> >>>>>>[email protected]
> >>>>>>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
> >>>>>[email protected]
> >>>>>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
> >>>[email protected]
> >>>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
> >>[email protected]
> >>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
> > [email protected]
> > 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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" <[email protected]>
> To: <[email protected]>
> 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" <[email protected]>
>>To: <[email protected]>
>>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"
>
> <[email protected]>
>
>>>>To: <[email protected]>
>>>>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: [email protected] on behalf of Victor
>>>>>>Shcherbatyuk
>>>>>>Sent: Tue 8/23/2005 5:00 PM
>>>>>>To: [email protected]
>>>>>>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: [email protected] on behalf of Brad
>
> Midgley
>
>>>>>>Sent: Mon 8/22/2005 9:22 AM
>>>>>>To: [email protected]
>>>>>>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
>>>>>>[email protected]
>>>>>>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
>>>>>[email protected]
>>>>>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
>>>[email protected]
>>>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
>>[email protected]
>>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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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" <[email protected]>
To: <[email protected]>
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" <[email protected]>
> To: <[email protected]>
> 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"
<[email protected]>
> >> To: <[email protected]>
> >> 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: [email protected] on behalf of Victor
> >>>> Shcherbatyuk
> >>>> Sent: Tue 8/23/2005 5:00 PM
> >>>> To: [email protected]
> >>>> 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: [email protected] on behalf of Brad
Midgley
> >>>> Sent: Mon 8/22/2005 9:22 AM
> >>>> To: [email protected]
> >>>> 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
> >>>> [email protected]
> >>>> 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
> >>> [email protected]
> >>> 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
> > [email protected]
> > 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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" <[email protected]>
To: <[email protected]>
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" <[email protected]>
>> To: <[email protected]>
>> 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: [email protected] on behalf of Victor
>>>> Shcherbatyuk
>>>> Sent: Tue 8/23/2005 5:00 PM
>>>> To: [email protected]
>>>> 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: [email protected] on behalf of Brad Midgley
>>>> Sent: Mon 8/22/2005 9:22 AM
>>>> To: [email protected]
>>>> 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
>>>> [email protected]
>>>> 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
>>> [email protected]
>>> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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" <[email protected]>
> To: <[email protected]>
> 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: [email protected] on behalf of Victor
>>> Shcherbatyuk
>>> Sent: Tue 8/23/2005 5:00 PM
>>> To: [email protected]
>>> 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: [email protected] on behalf of Brad Midgley
>>> Sent: Mon 8/22/2005 9:22 AM
>>> To: [email protected]
>>> 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
>>> [email protected]
>>> 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
>> [email protected]
>> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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" <[email protected]>
To: <[email protected]>
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: [email protected] on behalf of Victor
>> Shcherbatyuk
>> Sent: Tue 8/23/2005 5:00 PM
>> To: [email protected]
>> 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: [email protected] on behalf of Brad Midgley
>> Sent: Mon 8/22/2005 9:22 AM
>> To: [email protected]
>> 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
>> [email protected]
>> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Brad,
I've tested with usleep(1000), but it make no difference?=20
Regards,
Victor.
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Brad
Midgley
Sent: Wednesday, August 24, 2005 18:41 PM
To: [email protected]
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
[email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/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: [email protected]
[mailto:[email protected]] On Behalf Of Brad
Midgley
Sent: Friday, August 26, 2005 7:11 AM
To: [email protected]
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: [email protected] on behalf of Victor=20
> Shcherbatyuk
> Sent: Tue 8/23/2005 5:00 PM
> To: [email protected]
> 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: [email protected] on behalf of Brad=20
> Midgley
> Sent: Mon 8/22/2005 9:22 AM
> To: [email protected]
> 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
> [email protected]
> 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
[email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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: [email protected] on behalf of Victor Shcherbatyuk
> Sent: Tue 8/23/2005 5:00 PM
> To: [email protected]
> 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: [email protected] on behalf of Brad Midgley
> Sent: Mon 8/22/2005 9:22 AM
> To: [email protected]
> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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" <[email protected]>
To: <[email protected]>
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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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: [email protected] on behalf of Victor Shcherbatyuk
Sent: Tue 8/23/2005 5:00 PM
To: [email protected]
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: [email protected] on behalf of Brad Midgley
Sent: Mon 8/22/2005 9:22 AM
To: [email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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: [email protected] on behalf of Brad Midgley
Sent: Mon 8/22/2005 9:22 AM
To: [email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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" <[email protected]>
To: <[email protected]>
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" <[email protected]>
> To: <[email protected]>
> 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" <[email protected]>
>> To: <[email protected]>
>> 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: [email protected]
>> >> [mailto:[email protected]] 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
>> >> [email protected]
>> >> 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
>> >> [email protected]
>> >> 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
>> > [email protected]
>> > 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Thanks Victor I will also try to port to Symbian devices to see the
improvements ...Ciao Roberto
----- Original Message -----
From: "Victor Shcherbatyuk" <[email protected]>
To: <[email protected]>
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" <[email protected]>
> To: <[email protected]>
> 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: [email protected]
> >> [mailto:[email protected]] 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
> >> [email protected]
> >> 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
> >> [email protected]
> >> 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
> > [email protected]
> > 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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" <[email protected]>
To: <[email protected]>
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: [email protected]
>> [mailto:[email protected]] 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
>> [email protected]
>> 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
>> [email protected]
>> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/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: [email protected]
[mailto:[email protected]] On Behalf Of Brad
Midgley
Sent: Thursday, July 28, 2005 23:09 PM
To: [email protected]
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
> <[email protected]>
> To: <[email protected]>
> 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
>> <[email protected]>
>> To: <[email protected]>
>> 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: [email protected]
>>>> [mailto:[email protected]] 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
>>>> [email protected]
>>>> 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
>>>> [email protected]
>>>> 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
>>> [email protected]
>>> 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
>> [email protected]
>> 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
> [email protected]
> 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
[email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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: [email protected]
> [mailto:[email protected]] On Behalf Of Brad
> Midgley
> Sent: Wednesday, September 07, 2005 5:24 AM
> To: [email protected]
> 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
> [email protected]
> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/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: [email protected]
[mailto:[email protected]] On Behalf Of Brad
Midgley
Sent: Wednesday, September 07, 2005 5:24 AM
To: [email protected]
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
[email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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" <[email protected]>
To: <[email protected]>
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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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....