search for: qlp_coeff

...e "private/cpu.h" #include "private/crc.h" #include "private/fixed.h" @@ -1738,10 +1739,11 @@ /* decode the subframe */ memcpy(decoder->private_->output[channel], subframe->warmup, sizeof(FLAC__int32) * order); - if(bps <= 16 && subframe->qlp_coeff_precision <= 16) - decoder->private_->local_lpc_restore_signal_16bit(decoder->private_->residual[channel], decoder->private_->frame.header.blocksize-order, subframe->qlp_coeff, order, subframe->quantization_level, decoder->private_->output[channel]+order); - else i...

...autocorrelation_asm_ia32_3dnow(const 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_N...

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

...r.c,v retrieving revision 1.87 diff -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__int3...

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

If I compile libFLAC with GCC 7.1 I see many warnings like lpc.c: In function 'FLAC__lpc_compute_residual_from_qlp_coefficients': lpc.c:489:18: warning: this statement may fall through [-Wimplicit-fallthrough=] case 32: sum += qlp_coeff[31] * data[i-32]; ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ lpc.c:490:5: note: here case 31: sum += qlp_coeff[30] * data[i-31]; ^~~~ lpc.c:490:18:...

...do first, since it's relatively simple. In stepping through some runs, it appears that 'order' mod 4 is always 0. Is that guaranteed, either by the format or by higher functions in the reference decoder? Also, what assumptions can I make about the alignment of 'data' and 'qlp_coeff'? It would be really nice if these were both doubleword-aligned. Finally, in a more general context, is there an easy way to build for profiling, or do I have to edit the makefiles? I'm using gcc and gprof. Thanks in advance, -Brady -- Brady Patterson (brady@spaceship.com) Do you know...

...t/archzoom.cgi/eric@petta-tech.com--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_...

...ns, it appears that 'order' mod 4 is always 0. Is > that guaranteed, either by the format or by higher functions in the reference > decoder? No, 1 <= order <= 32. There is -l option :). > Also, what assumptions can I make about the alignment of 'data' and > 'qlp_coeff'? It would be really nice if these were both doubleword-aligned. Everything should be 4 byte aligned, residual is 8 byte aligned on GNU libc based system. If this isn't good enough (and it isn't for SSE2), we will have to replace appropriate malloc calls. However, you can copy qlp_coe...

...r. > Everything should be 4 byte aligned, residual is 8 byte aligned on GNU > libc based system. If this isn't good enough (and it isn't for SSE2), > we will have to replace appropriate malloc calls. It isn't, and I'm currently doing just that. > However, you can copy qlp_coeffs on stack for better alignment. You mean copying them into a local array in read_subframe_lpc_(), right? I'd still have to manually align that array, though, or am I missing something? > IIRC powerpc has performance counters, if you want the best code, use them. Good idea. Cpocuba, or h...

>> Ok I will give it a try and see what I can come up with. > Is the most interesting data the [frame] and [subframe] info? > Is the qlp_coeff[], warmpup[] and parameter[] data for each frame/subframe important? Yes, it would be nice if MetaFLAC will show minimum and maximum values of parameters (if are not constant/fixed) for the stream. And it would be VERY NICE if you implement "--is-subset" switch. "metaflac --is-subs...

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]) &gt...

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

...d 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 GCC 64-bit: 79.5 ICC 64-bit: 81.2 VS10 64-bit: 81.1 VS12 64-bit: 83.3 According to a profiler, FLAC__lpc_compute_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__int...

...@ .loop2_end: .end: + pop ebx pop edi pop esi ret @@ -804,7 +814,11 @@ .i_32: sub edi, esi neg eax - lea edx, [eax + eax * 8 + .jumper_0] + lea edx, [eax + eax * 8 + .jumper_0 - .get_eip0] + call .get_eip0 +.get_eip0: + pop eax + add edx, eax inc edx mov eax, [esp + 28] ; eax = qlp_coeff[] xor ebp, ebp @@ -1203,7 +1217,11 @@ .x87_32: sub esi, edi neg eax - lea edx, [eax + eax * 8 + .jumper_0] + lea edx, [eax + eax * 8 + .jumper_0 - .get_eip0] + call .get_eip0 +.get_eip0: + pop eax + add edx, eax inc edx ; compensate for the shorter opcode on the last iteration mov eax...

On Mon, Dec 1, 2014 at 10:40 PM, ???? ?????? <bart.gopnik at gmail.com> wrote: > Please help me solve the following problem: > > FLAC tools have a lots of warnings about non-subset files during > encoding, but unfortunately don't have easy way to check/test existing > FLAC stream for subset compliance. > > "flac -a" generates the big text file that has

--- Miroslav Lichvar <lichvarm@phoenix.inf.upol.cz> wrote: > On Wed, Nov 14, 2001 at 09:37:47AM -0800, Josh Coalson wrote: > > cpu support for 3dnow and sse can be easily detected at > > runtime. I turned off 3dnow by default because it is > > implicated in some crashes. > > Hmm, i never have any crash. Can i get more informations about these > crases? Or you

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)

...;=8) (not a problem for me right 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: s...

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