search for: bitbuffer

...=compile /opt/crosstool/gcc-3.4.1-glibc-2.2.5/armv5b-softfloat-linux/bin/armv5b-softfloat-linux-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I./include -I../../include -O2 -DNDEBUG -O3 -fomit-frame-pointer -funroll-loops -finline-functions -Wall -W -Winline -DFLaC__INLINE=__inline__ -g -O2 -MT bitbuffer.lo -MD -MP -MF ".deps/bitbuffer.Tpo" -c -o bitbuffer.lo bitbuffer.c; \ then mv -f ".deps/bitbuffer.Tpo" ".deps/bitbuffer.Plo"; else rm -f ".deps/bitbuffer.Tpo"; exit 1; fi /opt/crosstool/gcc-3.4.1-glibc-2.2.5/armv5b-softfloat-linux/bin/armv5b-softfloat-linu...

...se memmove (is this usually assembly in libc too?) and also the endpoints looked wrong, for my full patch see below. speedup for me was around 3% the second patch got another 2%. a question though, why do you have: + *(++vals); in two places instead of just ++vals; ? Josh Index: bitbuffer.c =================================================================== RCS file: /cvsroot/flac/flac/src/libFLAC/bitbuffer.c,v retrieving revision 1.55 diff -u -r1.55 bitbuffer.c --- bitbuffer.c 25 Jan 2005 02:37:08 -0000 1.55 +++ bitbuffer.c 25 Jan 2005 02:39:52 -0000 @@ -228,11 +228,27 @@ /*...

....tar.gz?download > > 2. do > ./configure && make && make check > This will build all code and run all the tests. flac-1.0.3_beta compilation breaks for me with message: make[3]: Entering directory `/home/andrei/tmp/123/flac-1.0.3_beta/src/libFLAC' source='bitbuffer.c' object='bitbuffer.lo' libtool=yes \ depfile='.deps/bitbuffer.Plo' tmpdepfile='.deps/bitbuffer.TPlo' \ depmode=none /bin/sh ../../depcomp \ /bin/sh ../../libtool --mode=compile gcc -DPACKAGE=\"flac\" -DVERSION=\"1.0.3_beta\" -DHAVE_DLFCN_H=1 -DHAVE_...

Josh Coalson <xflac@yahoo.com> wrote: > thanks for the patch. No prob :) > also, if you have miroslav's patch again a more updated version > of bitbuffer.c that would be great. I have been meaning to get > around to applying it for a long time. This is Miroslav's patch, from the mailing list post I dug up in the archives: --- orig/src/libFLAC/bitbuffer.c +++ mod/src/libFLAC/bitbuffer.c @@ -62,6 +62,24 @@ * keeping in mind the limit from...

thanks for the patch. also, if you have miroslav's patch again a more updated version of bitbuffer.c that would be great. I have been meaning to get around to applying it for a long time. btw how are you playing it on the ipod? not sure how to help out with lpc_restore_signal(). there are x86 and PPC versions of the routines in CVS that might be good references. it is basically a multiply-a...

...looking at compiler output in asm, and counting ops (especially branch calls). Anyways, here goes the patch I described in my first paragraph: * added files {arch}/flac/flac--ipod/flac--ipod--1.1.0/eric@petta-tech.com--2004b-ordinary/patch-log/patch-27 * modified files --- orig/src/libFLAC/bitbuffer.c +++ mod/src/libFLAC/bitbuffer.c @@ -233,11 +233,26 @@ /* first shift the unconsumed buffer data toward the front as much as possible */ if(bb->total_consumed_bits >= FLAC__BITS_PER_BLURB) { +#if FLAC__BITS_PER_BLURB == 8 + /* + * memset and memcpy are usually implemented in assembl...

...ATE, &sampleRate ); speex_decoder_ctl( pCodecDecoderState, SPEEX_GET_FRAME_SIZE, &decoderFrameSize ); speex_decoder_ctl( pCodecDecoderState, SPEEX_SET_ENH, &enabled ); // speex_bits_init( &codecBits ); } uint TVoiceCodec::encode( byte *rawsoundbuffer, uint length, char *bitbuffer, float gain ) { if( !pCodecEncoderState ) return 1; // copy raw voice data to temporary codec raw voice data buffer memcpy( pCodecRawBufferCur, rawsoundbuffer, length ); pCodecRawBufferCur += length; // determine the size of data uint buffersize = (int)( pCodecRawBufferCur...

...es (this is a 44.1/16bit/stereo file, so about 0.5 seconds). I have put the file up at <http://people.debian.org/~mdz/flac-test-case-1.wav>. Here is a gdb backtrace at the point where it is allocating gobs of memory: (gdb) bt #0 0x400ba565 in memset () from /lib/libc.so.6 #1 0x805f782 in bitbuffer_resize_ (bb=0x4085c800, new_capacity=134479872) at bitbuffer.c:62 #2 0x805f8ec in bitbuffer_grow_ (bb=0x4085c800, min_bytes_to_add=33554433) at bitbuffer.c:86 #3 0x805f976 in bitbuffer_ensure_size_ (bb=0x4085c800, bits_to_add=268435453) at bitbuffer.c:94 #4 0x8060226 in FLAC__bitbuff...

I have just released a source distribution which is the candidate for the 1.0.3 release. At this time I would ask anyone who is willing to help test it to do the following: 1. download the tarball and unzip it: http://prdownloads.sourceforge.net/flac/flac-1.0.3_beta-src.tar.gz?download 2. do ./configure && make && make check This will build all code and run all the tests.

...gt; > stack > > trace, it worked. Any ideas how to track down the problem? > > don't you just hate those? maybe just manually turning > on basic debug info in the release build would get you > enough to narrow it down. OK, here's the stack trace: (gdb) bt #0 FLAC__bitbuffer_read_raw_uint32 (bb=0x20000000008c8048, val=0x80000fffffffa498, bits=24, read_callback=0x20000000003b1008, client_data=0x60000000002beb20) at bitbuffer.c:1107 #1 0x2000000000123dc0 in stream_decoder_read_metadata_ ( decoder=0x60000000002beb20) at stream_decoder.c:633 #2 0x2000000000...

...gt; > &decoderFrameSize ); > > speex_decoder_ctl( pCodecDecoderState, SPEEX_SET_ENH, > > &enabled ); > > // > > speex_bits_init( &codecBits ); > > } > > > > uint TVoiceCodec::encode( byte *rawsoundbuffer, uint length, char > > *bitbuffer, float gain ) > > { > > if( !pCodecEncoderState ) > > return 1; > > > > // copy raw voice data to temporary codec raw voice data buffer > > memcpy( pCodecRawBufferCur, rawsoundbuffer, length ); > > pCodecRawBufferCur += length; > > &...

...LAC make[2]: Entering directory `/opt/flac-0.8/src/libFLAC' /bin/sh ../../libtool --mode=compile gcc -DPACKAGE=\"flac\" -DVERSION=\"0.8\" -I. -I. -I./include -I ../../include -Wall -W -O3 -fomit-frame-pointer -funroll-loops -ffast-math -finline-functions -DNDEBUG -c bitbuffer.c mkdir .libs gcc -DPACKAGE=\"flac\" -DVERSION=\"0.8\" -I. -I. -I./include -I ../../include -Wall -W -O3 -fomit-frame-pointer -funroll-loops -ffast-math -finline-functions -DNDEBUG -Wp,-MD,.deps/bitbuffer.pp -c bitbuffer.c -fPIC -DPIC -o .libs/bitbuffer.lo gcc -DPACKAGE=\&qu...

Ok, here is a patch waiting for new CVS :). It works fine for me, but please check it before commiting... -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/bitbuffer.c.orig 2003-01-30 17:36:01.000000000 +0100 +++ src/libFLAC/bitbuffer.c 2003-01-30 21:53:18.000000000 +0100 @@ -51,6 +51,25 @@ */ static const unsigned FLAC__BITBUFFER_DEFAULT_CAPACITY = ((65536 - 64) * 8) / FLAC__BITS_PER_BLURB; /* blurbs */ +static const unsigned char byte_to_unary_table[] =...

...when I make mistakes. I have lots to learn so I'm sure I'll make many. Got the following error C:\Code\Vorbis\vorbis\lib\mdct.c(65) : error C2065: 'M_PI' : undeclared identifier and had to add #include "os.h" to vorbis\lib\mdct.h Also I had to add to the vorbis project bitbuffer.c bitbuffer.h Is there someone who manages the windows project files that I can write to? Lars. --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' conta...

...d without > gaps or errors in the data? It may be a buggy sync message > (which wouldn't show up in the plugins since they are ignored). The decoded audio has burps in it. As you would expect if some frames aren't decoded. I also have another problem. free(bb->buffer) in FLAC__bitbuffer_free, eventually called by the seekable stream decoder delete causes my application to crash. Very strange. I wounder if my two problems are related. The bitbuffer gets data moved around when read it called, so maybe they are related. It really seems like there is some memory craziness going on....

On Sat, Jul 21, 2001 at 04:06:14PM -0400, Matt Zimmerman wrote: > Argh. Maybe libtool will have to get involved after all. I'll work on it > this afternoon. I think I give up. automake and libtool assume that the compiler will be able to assemble stuff, and compilers don't generally understand NASM input. I don't like the strip_fPIC bit, since just about anything that could

On Mon, Jan 24, 2005 at 06:31:21PM -0800, Josh Coalson wrote: > yes, a mere 2 years later it is checked in! > > speed improvement for me is roughly 17% testing flac files on > linux-i386. Thanks! In case you would like to check another old patch, I have attached updated patch for seekable stream decoder, originally posted on 09/07/2003. -- Miroslav Lichvar -------------- next

...( pCodecDecoderState, SPEEX_GET_FRAME_SIZE, > &decoderFrameSize ); > speex_decoder_ctl( pCodecDecoderState, SPEEX_SET_ENH, > &enabled ); > // > speex_bits_init( &codecBits ); > } > > uint TVoiceCodec::encode( byte *rawsoundbuffer, uint length, char > *bitbuffer, float gain ) > { > if( !pCodecEncoderState ) > return 1; > > // copy raw voice data to temporary codec raw voice data buffer > memcpy( pCodecRawBufferCur, rawsoundbuffer, length ); > pCodecRawBufferCur += length; > > // determine the size of data &gt...

On Sun, Jul 22, 2001 at 12:28:52AM -0700, Josh Coalson wrote: > 2. Applied Matt's last cleanup patch of 8 files. I did not apply the patch > to src/test_unit/main.c since it looks wrong. main.c is supposed to include > the local bitbuffer.h, not src/libFLAC/private/bitbuffer.h; I think the > current version is correct. Ah, I missed that there was a local bitbuffer.h. In that case, what I should have done was add bitbuffer.h to test_unit_SOURCES. > 6. 'Improved' the flac.sgml rule to fall back to docbook2man if there...

Josh Coalson wrote: > but > the bad news is that there is no way to determine the frame > length except by decoding. > Yes, I realized that... :-( > I'm not exactly sure what the read constraint you mention > means but it might be helpful to tweak the value for > FLAC__BITBUFFER_DEFAULT_CAPACITY in src/libFLAC/bitbuffer.c > to be something larger (just guessing). that value should > probably be exposed in the API. > Well, what is happening is that I get a call from a framework whenever there is data available to decode. Inside that function, I imagine two ch...