search for: lp_quantiz

Displaying 19 results from an estimated 19 matches for "lp_quantiz".

2005 Feb 02
0
two small-ish optimizations (death by a thousand cuts)
...m--2005a-normalperson/flac--ipod--1.1.0--patch-19/src/libFLAC/arm/lpc_asm.s -- Eric Wong --- orig/src/libFLAC/lpc.c +++ mod/src/libFLAC/lpc.c @@ -293,6 +293,209 @@ void FLAC__lpc_restore_signal(const FLAC__int32 residual[], unsigned data_len, const FLAC__int32 qlp_coeff[], unsigned order, int lp_quantization, FLAC__int32 data[]) { + register const FLAC__int32 *qlp0 = &qlp_coeff[(order-1)]; + register FLAC__int32 sum; + register const FLAC__int32 *history, *qlp; + + history = &data[(-order)]; + + switch (order) { + case 12: + for( ; data_len != 0; --data_len) { + sum = (qlp0[0] * histor...
2004 Oct 01
1
[PATCH] fix compile errors with asm disabled
...nst FLAC__real data[], unsigned data_len, unsigned lag, FLAC__real autoc[]); #endif #endif +#endif /* * FLAC__lpc_compute_lp_coefficients() @@ -146,17 +147,16 @@ void FLAC__lpc_restore_signal(const FLAC__int32 residual[], unsigned data_len, const FLAC__int32 qlp_coeff[], unsigned order, int lp_quantization, FLAC__int32 data[]); void FLAC__lpc_restore_signal_wide(const FLAC__int32 residual[], unsigned data_len, const FLAC__int32 qlp_coeff[], unsigned order, int lp_quantization, FLAC__int32 data[]); #ifndef FLAC__NO_ASM -#ifdef FLAC__CPU_IA32 -#ifdef FLAC__HAS_NASM +# ifdef FLAC__CPU_IA32 +#...
2004 Oct 06
3
flac-1.1.1 completely broken on linux/ppc and on macosx if built with the standard toolchain (not xcode)
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)
2007 Aug 31
2
1.2.0: Test suite failures on LP64 archs?
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
2014 Jan 14
1
PATCH for lpc_asm.nasm
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: wr...
2014 Jan 24
2
PATCH for lpc_intrin_sse41.c: faster shifts
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 << (FLAC__SUBFRAME_LPC_QLP...
2004 Sep 10
3
const issue in FLAC__lpc_compute_residual_from_qlp_coefficients (libFLAC/lpc.c:233)
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 a personnal lack of understanding of the difference in C between *data and data[] ? Will...
2004 Sep 10
1
altivec lpc_restore_signal
...---- next part -------------- ; $Name$ $Revision$ $Date$ .text .align 2 .globl _FLAC__lpc_restore_signal_asm_ppc_altivec_16 .globl _FLAC__lpc_restore_signal_asm_ppc_altivec_16_order8 _FLAC__lpc_restore_signal_asm_ppc_altivec_16: ; r3: residual[] ; r4: data_len ; r5: qlp_coeff[] ; r6: order ; r7: lp_quantization ; r8: data[] ; see src/libFLAC/lpc.c:FLAC__lpc_restore_signal() ; these is a PowerPC/Altivec assembly version which requires bps<=16 (or actual ; bps<=15 for mid-side coding, since that uses an extra bit) ; these should be fast; the inner loop is unrolled (it takes no more than ; 3*(or...
2004 Sep 10
3
Altivec, automake
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
2004 Sep 10
2
Altivec, automake
...ff -c -r1.87 stream_decoder.c *** stream_decoder.c 20 May 2003 00:01:50 -0000 1.87 --- stream_decoder.c 25 Jul 2004 23:17:39 -0000 *************** *** 101,110 **** void (*local_lpc_restore_signal)(const FLAC__int32 residual[], unsigned data_len, const FLAC__int32 qlp_coeff[], unsigned order, int lp_quantization, FLAC__int32 data[]); void (*local_lpc_restore_signal_64bit)(const FLAC__int32 residual[], unsigned data_len, const FLAC__int32 qlp_coeff[], unsigned order, int lp_quantization, FLAC__int32 data[]); void (*local_lpc_restore_signal_16bit)(const FLAC__int32 residual[], unsigned data_len, c...
2004 Sep 10
2
const issue in FLAC__lpc_compute_residual_from_qlp_coefficients (libFLAC/lpc.c:233)
...es@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 >> 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 comp...
2014 Jan 30
0
PATCH for lpc_intrin_sse41.c: faster shifts
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, but its max value is 15 so the code always work. > (max_shiftlimi...
2007 Sep 01
2
Re: 1.2.0: Test suite failures on LP64 archs?
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] * (FLAC__int64)data[i-1]) >> > lp_quantization); > (gdb) i loc > i = 0 I have figured out the problem now. The index vari...
2005 Jan 29
4
A couple of points about flac 1.1.1 on ppc/linux/altivec
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
2013 Oct 04
2
Again about encoding speed of different compiles
...te_residual_from_qlp_coefficients_wide() is one of the most CPU consuming. I added __restrict keyword to its parameters. before it was: void FLAC__lpc_compute_residual_from_qlp_coefficients_wide(const FLAC__int32 *data, unsigned data_len, const FLAC__int32 qlp_coeff[], unsigned order, int lp_quantization, FLAC__int32 residual[]) after: void FLAC__lpc_compute_residual_from_qlp_coefficients_wide(const FLAC__int32 * __restrict data, unsigned data_len, const FLAC__int32 * __restrict qlp_coeff, unsigned order, int lp_quantization, FLAC__int32 * __restrict residual) Encoding time, in seco...
2005 Jan 01
2
libFLAC bitbuffer optimizations
...now), but the inner loop for larger orders could be done using Duff's device and still be fast without getting much bigger. I reading up on ARM assembly right now. void FLAC__lpc_restore_signal(const FLAC__int32 residual[], unsigned data_len, const FLAC__int32 qlp_coeff[], unsigned order, int lp_quantization, FLAC__int32 data[]) { unsigned i; FLAC__int32 sum; const FLAC__int32 *history, *qlp; const int tmp = (0 - order - 1); for(i = data_len; i != 0; --i) { sum = 0; qlp = &qlp_coeff[order]; history = &data[tmp]; switch (order) { case 8: sum += (*(--qlp)) * (*(++history));...
2005 Oct 25
2
Re: Reg. FLAC decoding
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
2005 Oct 25
0
Re: Reg. FLAC decoding
...ck and is the easiest (it's just a multiply-accumulate-shift loop). unsigned i, j; FLAC__int32 sum; for(i = 0; i < data_len; i++) { sum = 0; for(j = 0; j < order; j++) sum += qlp_coeff[j] * data[i-j-1]; data[i] = residual[i] + (sum >> lp_quantization); } the next would probably be FLAC__fixed_restore_signal(), which is also easy, and FLAC__bitbuffer_read_rice_signed_block(), which is unfortunately complicated. Josh __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
2004 Dec 28
2
libFLAC bitbuffer optimizations
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