search for: msbs

...ed blurbs here. - */ - if(bb->consumed_bits > 0) { - save_blurb = blurb = buffer[i]; - cbits = bb->consumed_bits; - blurb <<= cbits; - - while(1) { - if(state == 0) { - if(blurb) { - for(j = 0; !(blurb & FLAC__BLURB_TOP_BIT_ONE); j++) - blurb <<= 1; - msbs += j; - - /* dispose of the unary end bit */ - blurb <<= 1; - j++; - cbits += j; - - uval = 0; - lsbs_left = parameter; - state++; - if(cbits == FLAC__BITS_PER_BLURB) { - cbits = 0; - CRC16_UPDATE_BLURB(bb, save_blurb, bb->read_crc16); - break...

...ed blurbs here. - */ - if(bb->consumed_bits > 0) { - save_blurb = blurb = buffer[i]; - cbits = bb->consumed_bits; - blurb <<= cbits; - - while(1) { - if(state == 0) { - if(blurb) { - for(j = 0; !(blurb & FLAC__BLURB_TOP_BIT_ONE); j++) - blurb <<= 1; - msbs += j; - - /* dispose of the unary end bit */ - blurb <<= 1; - j++; - cbits += j; - - uval = 0; - lsbs_left = parameter; - state++; - if(cbits == FLAC__BITS_PER_BLURB) { - cbits = 0; - CRC16_UPDATE_BLURB(bb, save_blurb, bb->read_crc16); - break...

Pulled from my Arch archive, this following patch seems to have made quite a difference in getting my ARM7TDMI chip to play FLAC (compression levels 0-2) on my ipod. I don't have benchmarks with hard numbers, but playing with skips vs playing without skips is a fairly noticeable difference. memcpy and memset on uClibc are optimized in asm for the ARM7TDMI in uClibc. Other hardware/libc

...======================== RCS file: /cvsroot/flac/flac/src/libFLAC/bitreader.c,v retrieving revision 1.15 diff -u -r1.15 bitreader.c --- src/libFLAC/bitreader.c 28 Feb 2008 05:34:26 -0000 1.15 +++ src/libFLAC/bitreader.c 14 Mar 2008 11:07:07 -0000 @@ -69,13 +69,12 @@ #endif /* counts the # of zero MSBs in a word */ #define COUNT_ZERO_MSBS(word) ( \ - (word) <= 0xffff ? \ - ( (word) <= 0xff? byte_to_unary_table[word] + 24 : byte_to_unary_table[(word) >> 8] + 16 ) : \ - ( (word) <= 0xffffff? byte_to_unary_table[word >> 16] + 8 : byte_to_unary_table[(word) >> 24] ) \ +...

...its into register; * must remember to flush them back to *br before calling other - * bitwriter functions that use them, and before returning */ - register unsigned cwords; - register unsigned cbits; + * bitreader functions that use them, and before returning */ + unsigned cwords, words, lsbs, msbs, x, y; + unsigned ucbits; /* keep track of the number of unconsumed bits in word */ + uint32_t b; + int *val, *end; FLAC__ASSERT(0 != br); FLAC__ASSERT(0 != br->buffer); /* WATCHOUT: code does not work with <32bit words; we can make things much faster with this assertion */ FLAC__AS...

...its into register; * must remember to flush them back to *br before calling other - * bitwriter functions that use them, and before returning */ - register unsigned cwords; - register unsigned cbits; + * bitreader functions that use them, and before returning */ + unsigned cwords, words, lsbs, msbs, x, y; + unsigned ucbits; /* keep track of the number of unconsumed bits in word */ + brword b; + int *val, *end; FLAC__ASSERT(0 != br); FLAC__ASSERT(0 != br->buffer); /* WATCHOUT: code does not work with <32bit words; we can make things much faster with this assertion */ FLAC__ASSE...

--- src/libFLAC/include/private/bitmath.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/libFLAC/include/private/bitmath.h b/src/libFLAC/include/private/bitmath.h index 61b0e03..d32b1a7 100644 --- a/src/libFLAC/include/private/bitmath.h +++ b/src/libFLAC/include/private/bitmath.h @@ -42,7 +42,7 @@ #endif /* Will never be emitted for MSVC, GCC, Intel compilers */

...ay touch 2 or 4 bytes depending on the operand size, but doesn't specifically mention that a 64 bit operation size touches 8 bytes - and it doesn't mention anything at all about operand size and access size in BTR/BTS/BTC (unless it's implied as part of the discussion about encoding the MSBs of a constant bit offset in the offset of the addressing mode). Is that an oversight? > The > access size generally is meaningless from a semantic standpoint > (little-endian being the only sane model), but the access size *can* > have performance implications for the write queue forw...

On Sun, Jul 14, 2013 at 5:56 AM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > 1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30) > changed a bunch of btrl/btsl instructions to btr/bts, with the following > justification: > > The inline assembly for the bit operations has been changed to remove > explicit sizing hints on the instructions, so the

Jean-Marc Valin wrote: >Well, I guess the first thing to look is whether your DSP can actually >do either 16x32=>48 or 16x32=>32 (keeping the MSBs), which is what the >smulwb does on ARM. If that's the case, you can gain a lot of speed (use >one instruction for 16x32 instead of three). Otherwise, replacing the >32x32 multiplies by 16x16 is probably a good thing. > > One thing I've noticed so far in the filter_mem2 cod...

Hello, ????????at the beginning I want to underline that I've read SpeeX documentation and did some tests. I know that SpeeX was designed for networks in which packets arrive without errors, or don't arrive at all. SpeeX is very attractive if we consider low bit rates. I need to use SpeeX in very noisy environment, where speech quality doesn't matter, I'm interested in 2kb/s

...e_bits = 134733184 buffer = ( const FLAC__blurb *) 0x8060228 "o?z\023\017\a???\216???c??????vc?\201q\030NE+\030\213?5*?k??R2?\035?\207iP!?\237??oQ??\207?\202\"?\235\220?\212Us??v??f??\231%\233??qJ??oLF\024???>?j%\237??" i = 44552 j = 8 val_i = 70816 cbits = 1 uval = 631 msbs = 1 lsbs_left = 1 blurb = 158 '\236' save_blurb = 196 '?' state = 1 #1 0x4021f88d in read_residual_partitioned_rice_ (decoder=0x805ba58, predictor_order=3, partition_order=14, partitioned_rice_contents=0x805f478, residual=0x807dd80) at stream_decoder.c:1975 rice_parameter...

Hello, I am looking for Ogg-vorbis streams with block sizes 4096 and 8192. Please let me how do generate these streams. This is to test our fixed-point implementation... Best regards Kiran Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential

Jean-Marc Valin wrote: >>I have the encoder and decoder running now and have verified that the >>encoder is bit-exact wrt to the fixed-point code running on x86 for the >>same 30-second audio sample. Encode and decode together run in >>real-time for 8KHz data, complexity=3, on 120MHz C5509 when code and >>data are all in on-chip SRAM. I have not tested the

Hi Andy, Thanks for checking! I do see an issue on Tesla as well (at least G92, and I believe someone else reported on a GT215 or GT218). However I haven't confirmed that it's the identical issue to what I see on Fermi with quite as much certainty as what I've checked on a GF108. (For the G92, the texture buffer object test fails in the same way it does on Fermi, but there could be

...e15db0 100644 --- a/src/libFLAC/bitreader.c +++ b/src/libFLAC/bitreader.c @@ -43,7 +43,7 @@ #include "share/endswap.h" /* Things should be fastest when this matches the machine word size */ -/* WATCHOUT: if you change this you must also change the following #defines down to COUNT_ZERO_MSBS below to match */ +/* WATCHOUT: if you change this you must also change the following #defines down to FLAC__clz_uint32 below to match */ /* WATCHOUT: there are a few places where the code will not work unless uint32_t is >= 32 bits wide */ /* also, some sections currently only have...

1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30) changed a bunch of btrl/btsl instructions to btr/bts, with the following justification: The inline assembly for the bit operations has been changed to remove explicit sizing hints on the instructions, so the assembler will pick the appropriate instruction forms depending on the architecture and the context. Unfortunately,

...t it basically applies to all 32-bit digests, + * which is why it was moved to common header file. + * + * In case you wonder why A-D are declared as long and not + * as MD5_LONG. Doing so results in slight performance + * boost on LP64 architectures. The catch is we don't + * really care if 32 MSBs of a 64-bit register get polluted + * with eventual overflows as we *save* only 32 LSBs in + * *either* case. Now declaring 'em long excuses the compiler + * from keeping 32 MSBs zeroed resulting in 13% performance + * improvement under SPARC Solaris7/64 and 5% under AlphaLinux. + * Well, to be...

Hi, This is the fifth version of this patch series. With the Versatile Express TC2, it''s possible to boot only with A7 or A15. If the user choose to boot with only A7, the CPU ID will start at 0x100. As Xen relies on it to set the logical ID and the GIC, it won''t be possible to use Xen with this use case. This patch series is divided in 3 parts: - Patch 1: prepare Xen

George has release acked all of these. Otherwise mostly minor updates this time around. Summary: A == acked, M == modified A xen: arm64: Add 8250 earlyprintk support A xen: arm64: Add Basic Platform support for APM X-Gene Storm. A xen: arm64: Add APM implementor id to processor implementers. M xen: arm: add a quirk to handle platforms with unusual GIC layout A xen: arm: allow platform