similar to: How to check for 64-bit CPU?

On 29 December 2015 at 13:33, Rafa?l Carr? <funman at videolan.org> wrote: > On 12/28/2015 08:35 PM, lvqcl wrote: >> 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 >>

On 29 December 2015 at 08:08, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > I would suggest: > > #if SIZEOF_VOIDP == 8 I believe this is not portable. At least on my machine ("4.2.1 Compatible FreeBSD Clang 3.4.1 (tags/RELEASE_34/dot1-final 208032)") it's not defined. Probably this one comes closest: #define __SIZEOF_POINTER__ 8 Riggs

In the precompute_partition_info_sums_ function, instead of selecting 64-bit accumulator when the signal bps is larger than 16, revert to the original approach based on partition size, but make room for few extra bits to not overflow with unusual signals where the average residual magnitude may be larger than bps. It slightly improves the performance with standard encoding levels and 16-bit files

> Oliver St?neberg wrote: > > > This is simply fixed by putting those unused constants into the > > proper defines. I attached a patch against git 70b078c. > > Unfortunately it breaks x86_64 build (where FLAC__CPU_X86_64 is defined, and > FLAC__CPU_IA32 isn't). Maybe it's simpler to turn them into #defines such as > > #define

1) src/share/grabbag/snprintf.c, line 42: 'on systems with a norrmal ISO C99' 'norrmal' -> 'normal' 2) src/flac/encode.c, line 1661: '(eg, very short files, < 10000 fames)' 'fames' -> frames? samples? bytes? 3) configure.ac, line 140: 'AM_CONDITIONAL(FLAC__CPU_X86_64, test "x$cpu_x86_64" = xtrue)' Not sure about this, but

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: >> 3) configure.ac, line 140: 'AM_CONDITIONAL(FLAC__CPU_X86_64, test "x$cpu_x86_64" = xtrue)' >> >> Not sure about this, but other names inside AM_CONDITIONALs begin with FLaC__, >> not FLAC__. A quote from configure.ac: "NOTE that for many of the AM_CONDITIONALs >> we use the prefix FLaC__ instead of FLAC__ since

Hi all, I just noticed this: https://sourceforge.net/p/flac/feature-requests/91/ a request for support of 32 bit audio data. The request has been around since 2008. Had two inial impressions: * Would adding this break brackwards compatibility too badly? Obviously decoding of 32 bit encoded data would not work with older versions of flac. * This is nuts. 24 bits has a dynamic range of

The following series adds initial vector support for PowerPC64. On POWER9, flac --best is about 3.3x faster. Amitay Isaacs (2): Add m4 macro to check for C __attribute__ features Check if compiler supports target attribute on ppc64 Anton Blanchard (5): configure.ac: Remove SPE detection code configure.ac: Add VSX enable/disable configure.ac: Fix FLAC__CPU_PPC on little endian, and add

MSVS profiler shows that the following code in stream_encoder.c takes several percent of CPU time: for(rice_parameter = 0, k = partition_samples; k < mean; rice_parameter++, k <<= 1) ; this code is equivalent to: rice_parameter = 0; k = partition_samples; while(k < mean) { rice_parameter++; k <<= 1; } The idea was to accelerate it:

Hello everybody, just to let you know what happened in the meantime: I was able to open a Service Request at Oracle. The issue is a known bug (Bug 6742788 : assertion panic at: zfs:zap_deref_leaf) The bug has bin fixed (according to Oracle support) since build 164, but there is no fix for Solaris 11 available so far (will be fixed in S11U7?). There is a workaround available that works

Thomas Zander wrote: > If you want to share the patch, I am happy to repeat some testing on > Sandy Bridge and Core2 with clang. The patch changes many files, libFLAC/bitwriter.c and test_libFLAC/bitwriter.c among them. So now I wait for the decision for patches #3 and #4 that I posted yesterday. > The slower decoding speed for 24 bit content on x86_64 seems > surprising, but

stream_encoder.c has the following code: /* try to keep qlp coeff precision such that only 32-bit math is required for decode of <=16bps streams */ if(subframe_bps <= 16) { ... But FLAC can convert 16-bit input to 17-bit if mid-side coding is used. So, does it make sense to compare subframe_bps with 17? (The patch is attached. What do you think about it?) -------------- next part

Josh Coalson wrote: > excellent, thanks for the tip. this solves the problem for > autoconf-based builds, but still not sure how to do it for MSVC. Sorry, whats the problem with MSVC? Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "Microsoft's biggest weakness is

Hi all, The code currently in CVS gives a compile warning: memory.c: In function 'FLAC__memory_alloc_aligned': memory.c:52: warning: cast from pointer to integer of different size memory.c:52: warning: cast to pointer from integer of different size The patch below fixes this warning by detecting the sizeof (void*) at configure time and then using that for a little pointer

Erik de Castro Lopo wrote: > lvqcl, > > Would you be able to have alook at this one? I think its > Windows related: > > https://sourceforge.net/p/flac/feature-requests/114/ > The relevant changes are <http://git.xiph.org/?p=flac.git;a=commitdiff;h=6a6207b52a86b1d7980a5233e297c0fc948bed7d> and

This patch adds two AVX2 files and adds AVX2 support code into init_stream_internal_() in stream_encoder.c. -------------- next part -------------- A non-text attachment was scrubbed... Name: 05_avx2.zip Type: application/zip Size: 7279 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20141003/1471b3d6/attachment-0001.zip

On 14 March 2016 at 09:02, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > commit a9f84425cfd5d1dbfb564730ca80d0b588cb4f24 > Author: Erik de Castro Lopo <erikd at mega-nerd.com> > Date: Mon Mar 14 18:14:31 2016 +1100 > > libFLAC/cpu.c: Use `sigemptyset` instead of `__sigemptyset` > > The former is POSIX while the later is a GNU

On Thu, Jun 19, 2014 at 03:30:22PM +0400, lvqcl wrote: > BTW, what can you say about the following place in stream_decoder.c > in read_subframe_lpc_() function: > > /*@@@@@@ technically not pessimistic enough, should be more like > if( (FLAC__uint64)order * ((((FLAC__uint64)1)<<bps)-1) * ((1<<subframe->qlp_coeff_precision)-1) < (((FLAC__uint64)-1)

Or, I was originally thinking: rice_parameter = 0; k = partition_samples; if (k < mean) { int n = mean - k; rice_parameter += n; k <<= n; } (sorry for the hasty post) On Oct 11, 2013, at 10:34, Brian Willoughby wrote: > Hmm, maybe I'm missing something, but what about this: > > rice_parameter = 0; k = partition_samples; > int n = mean - k; > if (n >