search for: qlp_coeffs

I have noticed lpc slowdown both in encoding and decoding, not related to new config.h stuff. It seems there is wrong choosing of fastest possible version of lpc function. Patch is attached. -- Miroslav Lichvar -------------- next part -------------- Index: src/libFLAC/stream_decoder.c =================================================================== RCS file:

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

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

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

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

Howdy. I'm working on Altivec versions of some of the libFLAC functions. I figured the best candidates would be those that had MMX/SSE/3dnow versions, and I picked FLAC__lpc_restore_signal() to 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

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

...p_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_coeffs on stack for better alignment. > > 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. IIRC powerpc has performance counters, if you want the best code, use them. For gprof profiling patch...

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

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

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

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

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

So here is quick patch solving the problem, now it should be PIC. -- Miroslav Lichvar lichvarm@phoenix.inf.upol.cz -------------- next part -------------- --- lpc_asm.nasm.orig Wed Jul 18 02:23:40 2001 +++ lpc_asm.nasm Sat Nov 17 21:09:46 2001 @@ -59,10 +59,10 @@ ; ALIGN 16 cident FLAC__lpc_compute_autocorrelation_asm_ia32 - ;[esp + 24] == autoc[] - ;[esp + 20] == lag - ;[esp + 16] ==

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)

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

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