similar to: [PATCH 4/4] lpc_intrin_sse41 routines

This patch accelerates decoding of non-Subset 24-bit FLAC files (where lpc_order > 12). (The improved function is FLAC__lpc_restore_signal_wide_intrin_sse41(). It requires SSE4.1 and it's used only by 32-bit libFLAC) -------------- next part -------------- A non-text attachment was scrubbed... Name: 03_wide_decode.patch Type: application/octet-stream Size: 5502 bytes Desc: not available

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

Martijn van Beurden wrote: > Like I reported just before the release of 1.3.0 (mail of Fri, > 05 Apr 2013 08:25:10 +0200, to be specific), compiling on > Raspbian (Debian Wheezy, GCC 4.6) returns quite some warnings of > the type -Wcast-align. > > > CC lpc_intrin_sse2.lo > > CC lpc_intrin_sse41.lo > > CC md5.lo > > md5.c: In function

The patch does the following: 1. splits lpc_x86intrin.c to lpc_intrin_sse.c and lpc_intrin_sse2.c 2. adds FLAC__lpc_compute_residual_from_qlp_coefficients_intrin_sse2() function to lpc_intrin_sse2.c 3. adds lpc_intrin_sse41.c with two ..._wide_intrin_sse41() functions (useful for 24-bit en-/decoding) 4. adds precompute_partition_info_sums_intrin_sse2() / ...ssse3() and disables

Hi all, It sees that the most serious bug in the flac bug tracker: https://sourceforge.net/p/flac/bugs/413/ has been fixed in git. This fix alone is worth a new release so its time to work towards one. Things I need to do for this new release: * Deal with all current patches on the mailing list. * Review all bugs reported against 1.3.0 on the sf.net. * Testing and coordination of testing

Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: >> -msse for SSE code, -msse2 for SSE2 code, -msse4.1 for SSE4.1 code > > Yes, that was it. Brain fart. These flags were not needed on x86_64. > > Erik But now all C code is compiled with -msse2 and it won't work on older CPUs. Isn't it better to compile only necessary files with this flag?

lvqcl wrote: > It doesn't know about uint32_t type, so the definition of cpu_xgetbv_x86() fails. > It can be fixed by adding "#include share/compat.h" to cpu.c (or by using > FLAC__uint32 from FLAC/ordinals.h). Ok, added share/compat.h. > When I fix this, the following problem occurs: > > error LNK2019: unresolved external symbol ___cpuidex referenced in

It's not possible to use ia32/*.nasm code in 64-bit compiles. There's still no 64-bit asm code in FLAC. I'm not familiar with asm too, so I wrote SSE-accelerated code using intrinsics. This code uses two new preprocessor macros: FLAC__CPU_X86_64 (analogous to FLAC__CPU_IA32) and FLAC__HAS_X86INTRIN (analogous to FLAC__HAS_NASM) Patch for cpu.c/cpu.h adds CPU features (sse3, ssse3)

Erik de Castro Lopo wrote: > Unfortunately I've lost/forgotten my Xiph SVN password. While I get > that sorted out for the real release, the pre-releases are here: > > http://mega-nerd.com/tmp/flac-1.3.2pre1-win.zip > http://mega-nerd.com/tmp/flac-1.3.2pre1.tar.xz Forgot to mention that I have tested this on x86_64/linux, armhf/linux and powerpc/linux. Erik --

Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Unfortunately this patch doesn't apply. How was it generated? Would it be > possible to send a patch generated by Git because those usually do work. > > Erik I'm not very familiar with git... I hope that now I did everything correctly. The patch is in the attachment. -------------- next part -------------- A

Patch is here: https://github.com/openwrt/packages/commit/1263599f96f13f11d719ce336dfb6a639b32de98 . Probably needs to be modified for inclusion into mainline.

In stream_encoder.c there's the following code: #if defined FLAC__CPU_X86_64 /* and other 64-bit arch, too */ if(mean <= 0x80000000/512) { /* 512: more or less optimal for both 16- and 24-bit input */ #else if(mean <= 0x80000000/8) { /* 32-bit arch: use 32-bit math if possible */ #endif A) How to properly check for 64-bit architectures? I can check for "defined

This patch fixes bracket placement, extra space, etc in lpc_intrin_sse2.c and lpc_intrin_sse41.c -------------- next part -------------- A non-text attachment was scrubbed... Name: ident_fix.patch Type: application/octet-stream Size: 3480 bytes Desc: not available URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20170129/e59c42eb/attachment.obj>

This patch adds new SSE code: it's simpler but not faster so this new version is disabled by default. Maybe it will be faster on newer CPUs though... -------------- next part -------------- A non-text attachment was scrubbed... Name: predictor_intrin.patch Type: application/octet-stream Size: 5165 bytes Desc: not available Url :

This set of patches removes PPC/Altivec code from FLAC. I decided to split the patch into 5 parts to make it more simple: 1) removes FLAC__lpc_restore_signal_asm_ppc_altivec_16* from lpc.h and stream_decoder.c 2) removes PPC-specific code from cpu.c and cpu.h 3) removes PPC stuff from libFLAC/Makefile.lite and build/*.mk 4) removes as/gas/PPC-specific stuff from configure.ac and

Hi all, I have a new pre-reelase (with a GPG signature) up here: http://mega-nerd.com/tmp/flac-1.3.3rc1.tar.xz http://mega-nerd.com/tmp/flac-1.3.3rc1.tar.xz.asc This code is built from commit 10a28d482a8e48b806f61ab766992b2add98ec43 plus another commmit to change the version numbers which I will not be pushing to the public repo before the final release. Note that audio files encoded

lvqcl wrote: > > These versions of Visual Studio don't have stdint.h and > > all [u]intNN_t types. But now these types are everywhere > > in FLAC codebase. > > Here is the patch that fixes the problem: > it moves definitions of all [u]intNN_t types from share/compat.h > into new file share/msvc2005_int.h and then includes this file > into all files (via

Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Patch applied, tested, commited and pushed. Great. But, what about my other patches? I admit that many of them aren't necessary, but (imho) a couple of them are important. I can explain in detail why I think this.

About the removed assert in this commit: http://git.xiph.org/?p=flac.git;a=commitdiff;h=bc5113007a53be2c621d5eb5f4485eddf947ef37 It looks reasonable that if x.num_comments == 0 then x.comments is also NULL. Otherwise there's probably a leak somewhere that should be fixed. I found several places where the situation is reverse: comments can be 0 but num_comments is not; IMHO it makes sense

Erik de Castro Lopo wrote: > lvqcl wrote: > >> The set of four patches that remove dependency of libFLAC on win_utf8_io. >> >> Tested only on Windows, with MSVC and MSYS/MinGW (both autotools and makefile.lite) >> >> Please review, especially makefile patches, I'm not very familiar with them. > > Applied. All good. Thanks. But the 1st patch