similar to: Typos in the FLAC codebase

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

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

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

All(?) non-static functions have FLAC__ prefix. But precompute_partition_info_sums_32bit_asm_ia32_() and ..._intrin_sse2() and ..._intrin_ssse3() don't have it. This patch adds the prefix to them. -------------- next part -------------- A non-text attachment was scrubbed... Name: FLAC__prefix.patch Type: application/octet-stream Size: 6396 bytes Desc: not available Url :

> 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

After working on some more plugins I realized that the naming for flac's ordinal types were not going to cut it. There is too much chance for conflicts with other libraries/programs with names like 'bool' and 'uint32' so I went back and prefixed all flac ordinal types with 'FLAC__'. It makes the code a little harder to read until you get used to it but should make the

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

- INCLUDES is deprecated, and CPPFLAGS is an user-defined variable, use the proper AM_CPPFLAGS instead - Remove FLAC__INLINE definition, providing proper replacement for MSVC compilers. - Detect if we have C99 's lround and provide a replacement for windows... --- configure.ac | 32 ++++++++-------------------- examples/c/decode/file/Makefile.am

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)

Hi, after having some discussion of the FPU/SSE behavior on the sf.net bug tracker as well as having some other changes we made for the MAME/MESS project sitting around I thought about joining this list to make things easier. First one is the latest modification we had to make to compile with clang 3.4 x64. Here are the warnings the 1.2.1 source will give with it:

WAIT A MINUTE. You signed up for this mailing list to write that? -----Original Message----- From: flac-bounces@xiph.org [mailto:flac-bounces@xiph.org] On Behalf Of Dirk Sent: Friday, February 24, 2006 4:51 AM To: flac@xiph.org Subject: [Flac] H A T E What retard did the Flac API? It looks like what CS students do short before they leave university to become consultants. It's bloated

Decoding flac files is also prone to producing fragmented files. NTFS has the ability to completely avoid fragmentation if it is told the file size before hand, but that would require using special Windows-only functions. Increasing the write buffer from the default 512 bytes to 10 MB already reduces the problem tremendously. -------------- next part -------------- diff --git

I have tried to add a plunging to the "libtheora-1.0beta2" (network bandwidth measuring component was added) and Got it success for some far now the problem is when it is added the encoding process get extremely slow (around 20 seconds delay). I think that the problem is with my modified Makefile (some flag may have missed). the following is my modified Makefile.am which is in the

On Jan 2, 2007, at 1:56 PM, Josh Coalson wrote: >> OK, so I've been trying for a day now to get FLAC implementation in >> our apps. Suffice it to say that due to the "interesting" >> documentation [...] > > could you elaborate? Well, I've just never seen anything like it before. There's a step- through, to be sure, but I got more information out of

Is anyone else having trouble using the Apple OS X Mail.app with a Dovecot IMAP server? With 0.99.11 and 0.99.12 attempting to read certain messages using IMAP or IMAPS seems to put Mail.app into spinning pizza of death mode. Sniffing the connection, it looks like it happens after the client issues a BODY.PEEK[] and the server has responded with the (UID XXXX BODY[] {YYYY}...) and OK Fetch

I have tried to add a plunging to the "libtheora-1.0beta2" (network bandwidth measuring component was added) and Got it success for some far now the problem is when it is added the encoding process get extremely slow (around 20 seconds delay). I think that the problem is with my modified Makefile (some flag may have missed). the following is my modified Makefile.am which is in the

The sed expression is wrong, any flags with '-g' in any position gets zapped, for example: -mfloat-gprs=double (for powerpc e500) -> -mfloatprs=double. Which gives build errors and is perfectly valid in real use scenarios to switch from e500v1 (single precision) code to e500v2 (double precision) code. Signed-off-by: Gustavo Zacarias <gustavo at zacarias.com.ar> ---

Hi folks, I've discussed my desire to have multi location debug info support in LLVM IR with some of you before (and others - apologies if I forgot to CC you). I finally found some time to write down my thoughts about how this should work at the IR level and worked out the proposal below. Please let me know if this a) also does what you want out of it, b) seems like a sane way to encode

Thanks for the reply, But that still tries to read for itself from libogg... i need to be able to feed data only... it can never try and read for itself. That code is still trying to control the data flow. Basicly i need to operate like this. SetupCodec when i have data to give to the codec FeedDataToCodec(data) //Receive a bunch of callbacks somewhere returning me pcm data //Codec

OK, I did the last few patches and made the source release. Hope I got everything. I'll send out the standard announcement now. Thanks everyone. Josh __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/