similar to: two small-ish optimizations (death by a thousand cuts)

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 +++

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

Hello, I just tried to compile libFLAC (using Borland C++ Builder 6 on Windows). The compilers yells at me on line 233 of libFLAC/lpc.c *(residual++) = *(data++) - (sum >> lp_quantization); --> data is const and cannot be modified Funny thing is, if data is declared: const FLAC__int32 *data instead of const FLAC__int32 data[] everything is ok. Is this a bug in my compiler, or

On Tue, Jan 13, 2004 at 02:04:48PM -0800, Josh Coalson wrote: > --- Denis Chatelain <listes@octopodus.com> wrote: > > Hello, > > > > > > I just tried to compile libFLAC (using Borland C++ Builder 6 on > > Windows). > > > > The compilers yells at me on line 233 of libFLAC/lpc.c > > > > *(residual++) = *(data++) - (sum >>

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) *

Eric, I finally got around to your patches after Miroslav's. the first one (the memcpy/memset replacement) I had problems with, one because the buffers can overlap so I had to use 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: +

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

Here's what I listed in that email. Merging doesn't appear to be necessary. If you have any build problems, let me know. Note that my detection code is Darwin-specific. It's a BSD call (sysctl()), so a change to the platform-detection macros should enable it to work on other BSDs. However, I don't know what that would be, and I couldn't determine any safe way to do the check

Greetings list, I am working on a project on which we wish to use Speex with Google Automatic Speech Recognition (ASR) to transcribe Speex audio being sent on to Google ASR service and return us the text of the spoken audio in the Speex audio stream. However, Google ASR's Speex support requires the off-standard Speex-with-header-byte format, and my group cannot find any worthwhile

Greetings list, I am working on a project on which we wish to use Speex with Google Automatic Speech Recognition (ASR) to transcribe Speex audio being sent on to Google ASR service and return us the text of the spoken audio in the Speex audio stream. However, Google ASR's Speex support requires the off-standard Speex-with-header-byte format, and my group cannot find any worthwhile

The #endifs are mismatched, and my builds were failing because lpc_restore_signal* weren't getting declared. I've also commented the endifs to make them easier to match. Also, is there any reason #ifdefs for FLAC__HAS_NASM and FLAC__CPU_IA32 are separate and nested the way they are and not combined like this?: #if defined(FLAC__CPU_IA32) && defined(FLAC__HAS_NASM) I'm not

I've had this a long time but haven't submitted it yet. I've tried to mirror the ia32 setup, so there should be a new subdirectory src/libFLAC/ppc . The first two attachments go there. The third is a context diff for src/libFLAC/Makefile.am . I have some more modified files, which I figured I'd submit after the above are checked in and working for somebody other than me. If you

1) Two comments ";ASSERT(lp_quantization <= 31)" in the new functions ..._wide_asm_ia32() -- just to mention this constraint. (max. possible value of lp_quantization is 15, so it's not a problem) 2) "mov cl, ..." was replaced with "mov ecx, ..." (again Agner Fog, optimizing_assembly.pdf) summary: write to a partial register may result in false dependencies

It turns out that int64 shift is quite slow... This patch changes the code from: (FLAC__int32)(xmm.m128i_i64[0] >> lp_quantization) into: _mm_cvtsi128_si32(_mm_srli_epi64(xmm, lp_quantization)); Encoding of 24-bit .wav files with 32-bit FLAC became noticeably faster. The new code works only if quantization <= 32, but its max value is 15 so the code always work. (max_shiftlimit == (1

On Fri, Mar 14, 2008 at 07:36:31PM +0100, Miroslav Lichvar wrote: > attached are patches that improve decoding speed a bit. The first > patch improves the bit scan macro used for decoding unary values, the > second one adds a GCC inline assembly for bswap and the third patch > replaces the read_rice_block function. The third patch has a bug causing reading past input buffer, attaching

lvqcl wrote: > It turns out that int64 shift is quite slow... > > This patch changes the code from: > (FLAC__int32)(xmm.m128i_i64[0] >> lp_quantization) > into: > _mm_cvtsi128_si32(_mm_srli_epi64(xmm, lp_quantization)); > > Encoding of 24-bit .wav files with 32-bit FLAC became noticeably faster. > > > The new code works only if quantization <= 32,

Christian Weisgerber <naddy@mips.inka.de> wrote: > #0 0x0000000040d18810 in FLAC__lpc_compute_residual_from_qlp_coefficients_wide > (data=0x49e4c014, data_len=110, qlp_coeff=0x7f7ffffece70, order=1, > lp_quantization=14, residual=0x4fced000) at lpc.c:745 > 745 residual[i] = > data[i] - (FLAC__int32)((qlp_coeff[0] *

Hello, there is a chance for an integer overflow in opus_packet_parse_impl(): int padding=0; int p; do { if (len<=0) return OPUS_INVALID_PACKET; p = *data++; len--; padding += p==255 ? 254: p; } while (p==255); len -= padding; ... if (len<0) return OPUS_INVALID_PACKET; When ~16 MB of 0xff bytes is fed to the decoder, the padding

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I planning to upgrade from 1.1.2 dovecot to 1.1.3, that is if most people feel the 1.1.3 is more stable now than 1.1.2? I've downloaded the code and been going through and applying all the changes listed at the URL below: feed://hg.dovecot.org/dovecot-1.1/rss-log I gotten all of the applied except for the AIX one, I'm running on solaris.

I downloaded current version of FLAC sources and compiled it with: * GCC 4.8.1 (MSYS from http://xhmikosr.1f0.de/tools/) * Intel C++ Composer XE 2013 update 5 * MSVS 2010 SP1 * MSVS 2012 update 3 (SSSE3 and SSE4.1 code was disabled for all compilers) Stereo 24-bit WAV file was encoded with -8 preset. Encoding time, in seconds: GCC 32-bit: 209 ICC 32-bit: 130 VS10 32-bit: 116 VS12 32-bit: 114