similar to: const issue in FLAC__lpc_compute_residual_from_qlp_coefficients (libFLAC/lpc.c:233)

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

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

This lpc_restore_order was partially inspired by Miroslav's affd, though my (not very great) ARM asm version resembled this, as well. The other two reduce CPU array indexing overhead in loops a little. Additionally, a request for help: My not very optimized lpc_restore_signal is at the below URL, I couldn't get the ldm* instructions to work as advertised, even though I've talked

I think I've gotten FLAC__lpc_restore_signal() about as good as I'm going to get it. Here's what I have: -a new file, lpc_asm.s, which has the assembly routines -changes to cpu.h, cpu.c, and stream_decoder.c to enable them -changes to configure.in to support the new cpu stuff -a preliminary Makefile.am -maybe something else I'm forgetting Now automake complains that configure.in

Running the basic (--disable-thorough-tests) test suite, I get these failures round-trip test (rt-1-24-111.raw) encode... Segmentation fault (core dumped) ERROR FAIL: ./test_flac.sh fsd24-01 (--channels=1 --bps=24 -0 -l 16 --lax -m -e -p): encode...ERROR during encode of fsd24-01 FAIL: ./test_streams.sh on alpha and amd64. By contrast, i386 is fine. (All OpenBSD/4.2.) Could be a generic LP64

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 Thu, 27 Jan 2005, John Steele Scott wrote: > That looks fine to me as well. However, the best solution is something which > Luca suggested a few months ago, which is to use the functions defined in > altivec.h. These are C functions which map directly to Altivec machine > instructions. I am willing to help out, but I don't find the current lpc_asm.s > very easy to follow, and

Sorry for the delay in getting back to you., I was working on something else and just now got FLAC to work. Ok., FLAC files are playing now :) Cheers. There is a slight noise happening in the background., which i'm figuring out. I hope that it'll be solved soon. However, i wanted to know if there are any ARM specific optimizations that can be done. The processor is a 166MHz processor. Do

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

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

Sadly the latest optimization broke completely everything. The asm code isn't gas compliant. the libFLAC linker script has a typo, disabling the asm optimization and/or altivec won't let a correct build anyway. Instant fixes for the asm stuff: sed -i -e"s:;:\#:" on the lpc_asm.s to load address instead of addis+ori you could use lis and la and PLEASE use the @l(register)

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

There are following functions in bitreader.c: FLAC__bool FLAC__bitreader_read_unary_unsigned(FLAC__BitReader *br, unsigned *val); FLAC__bool FLAC__bitreader_read_rice_signed(FLAC__BitReader *br, int *val, unsigned parameter); FLAC__bool FLAC__bitreader_read_rice_signed_block(FLAC__BitReader *br, int vals[], unsigned nvals, unsigned parameter); * function FLAC__bitreader_read_rice_signed():

Hi, I finally got around to trying to update FLAC for the MAME/MESS project again. There were several issues I was able to fix and will submit patches later, but I hit one roadblock with GCC and clang: src/lib/libflac/libFLAC/stream_encoder.c:1696:43: error: cast from function call of type 'double' to non-matching type 'FLAC__int32' (aka 'int')

> Oliver St?neberg wrote: > > > I finally got around to trying to update FLAC for the MAME/MESS > > project again. There were several issues I was able to fix and will > > submit patches later, but I hit one roadblock with GCC and clang: > > > > src/lib/libflac/libFLAC/stream_encoder.c:1696:43: error: cast from function call > > of type

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

Hi, In the last days I've been taking as reference the example found in examples/c/encode/file/main.c. With it I've been able to encode a 2ch, 16 bps, 44100 sample rate input WAV file to a FLAC file. Now I've been trying to modify this example to encode a 2ch, 24 bps, 96000 sample rate WAV file. I have to say I'm a bit lost on how I should read the input file in this case, and

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

Hi all, I'm attempting to encode raw audio data using libFLAC++. My audio data is 16 bit, mono, 16000Hz. I set all the appropriate parameters on the encoder and then call init(). Everything appears to be ok. I don't know how to properly convert from char *data to the FLAC__int32 *[] requested by the process function. I think this is where my problem is. If I call process() like this:

Add OTP parity table. diff -urdpNX /usr/share/dontdiff -x Makefile dovecot.vanilla/src/lib-otp/otp-parity.c dovecot/src/lib-otp/otp-parity.c --- dovecot.vanilla/src/lib-otp/otp-parity.c 1970-01-01 03:00:00.000000000 +0300 +++ dovecot/src/lib-otp/otp-parity.c 2006-06-23 13:44:31.161891112 +0400 @@ -0,0 +1,29 @@ +/* + * OTP parity table. + * + * Copyright (c) 2006 Andrey Panin <pazke at