Return-Path: Message-ID: <000801c593a9$7df966a0$0201a8c0@NBVICTOR> From: "Victor Shcherbatyuk" To: References: <42E8F2B6.6090804@xmission.com> <001401c593a4$052752f0$0201a8c0@NBVICTOR> Subject: Re: [Bluez-devel] sbc and fixed-point progress MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Sender: bluez-devel-admin@lists.sourceforge.net Errors-To: bluez-devel-admin@lists.sourceforge.net Reply-To: bluez-devel@lists.sourceforge.net List-Unsubscribe: , List-Id: BlueZ development List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 28 Jul 2005 21:21:02 +0200 > possibly do some optimizations.... I think large precision parts under > some conditions can be ignored, cause they will be cut anyway when > converting by ignored I meant "partially ignored" of course, meaning some precision can be lost cause you will lose it anyway converting to 16 bit samples Regards, Victor ----- Original Message ----- From: "Victor Shcherbatyuk" To: Sent: Thursday, July 28, 2005 20:41 Subject: Re: [Bluez-devel] sbc and fixed-point progress > Brad, > > I'll send it in on weekend, still want to play a bit with precisions and > possibly do some optimizations.... I think large precision parts under > some conditions can be ignored, cause they will be cut anyway when > converting back to 16 bit integer at the end (or they have very small > impact on the final result). But, of course, it should be done 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" > To: > 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: bluez-devel-admin@lists.sourceforge.net >>> [mailto:bluez-devel-admin@lists.sourceforge.net] On Behalf Of Brad >>> Midgley >>> Sent: Monday, July 04, 2005 6:03 AM >>> To: BlueZ Mailing List >>> Subject: [Bluez-devel] sbc and fixed-point progress >>> >>> Guys, >>> >>> just FYI... >>> >>> I found a decent fixed point multiply that preshifts the values before >>> multiplying them. It keeps things in 32 bits. Most of the roundoff error >>> is taken care of in two additional terms. I think the result is >>> reasonable. >>> (http://www.accu.org/acornsig/public/caugers/volume2/issue6/fixedpoint.h >>> tml) >>> >>> If you compile with fixed-point on, libsbc will run both the fixed and >>> floating point calculations and flag errors when they differ too much. >>> It seems to be working well and has helped me catch a couple of >>> fixed-point calculation problems. >>> >>> I have the decoder almost finished but I probably need to split some >>> terms into integer and fixed-point components. Loading up >>> frame->sb_sample for example can have a big integer part but we want to >>> use most of the 32 bit fixed-point type for the fractional part. >>> >>> Brad >>> >>> >>> >>> ------------------------------------------------------- >>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >>> from IBM. Find simple to follow Roadmaps, straightforward articles, >>> informative Webcasts and more! Get everything you need to get up to >>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >>> _______________________________________________ >>> Bluez-devel mailing list >>> Bluez-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bluez-devel >>> >>> >>> 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 >>> Bluez-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bluez-devel >> >> >> ------------------------------------------------------- >> SF.Net email is Sponsored by the Better Software Conference & EXPO >> September >> 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices >> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & >> QA >> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf >> _______________________________________________ >> Bluez-devel mailing list >> Bluez-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bluez-devel > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September > 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Bluez-devel mailing list > Bluez-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bluez-devel ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel