similar to: [PATCH] two patches of doubtful usefulness

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

- 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

* Furthermore, use NDEBUG globally to detect the presence of building with more debug output information. AX_CHECK_ENABLE_DEBUG is easier to use, and nowadays Gnome has also switched to it from its own custom solution. --- configure.ac | 19 +------ include/FLAC/assert.h | 2 +- m4/ax_check_enable_debug.m4 | 124 ++++++++++++++++++++++++++++++++++++++++++

* Furthermore, use NDEBUG globally to detect the presence of building with more debug output information. AX_CHECK_ENABLE_DEBUG is easier to use, and nowadays Gnome has also switched to it from its own custom solution. --- configure.ac | 52 ++++++++++++------ include/FLAC/assert.h | 2 +- m4/ax_check_enable_debug.m4 | 124

Hi Erik, I've found a middleground for the problem of setting default CFLAGS. I've gone back to setting them if {C,CXX,CPP,LD}FLAGS are unset at the onset of the configure script (i.e., the user hasn't specified anything) and then proceed to set them to the defaults as before. This has been suggested before: https://lists.gnu.org/archive/html/autoconf/2006-04/msg00022.html In

Dear FLAC devs, I would like to get some of our patches merged into master. Most of them deal with adhering to GNU conventions, respectively not overriding flags/variables that are up to the user to set. For instance, honoring $(htmldir) is important, as we have installation paths for the documentation that differ from what is currently coded in the various Makefile.am's. Regards David

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

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:

Hi Bernhard, It seems like I messed up somewhere in the lpc code. However, it seems like your patch is also removing some code, which is probably why you see small differences between your asm version and the fixed point. I don't have my setup working at the moment, but could you test the following patch: Index: lpc_bfin.h ===================================================================

On Thu, Jun 19, 2014 at 06:25:57PM +0400, lvqcl wrote: > Now I wonder why evaluate_lpc_subframe_() function in stream_encoder.c contains > almost the same code, but without any comments that it's not enough pessimistic: > evaluate_lpc_subframe_(): > > if(subframe_bps + qlp_coeff_precision + FLAC__bitmath_ilog2(order) <= 32) > if(subframe_bps <= 16 &&

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)

Hello Jean-Marc, I disabled the Blackfin optimization functions one by one and found the error in libspeex/lpc_bfin.h in the autocorrelation computation. Compared to the fixed-point-variant of that function (from lpc.c), the blackfin-code produces correct values except for the zero offset value. Additionally, the loop after the ASM-code assigned values (ac32) wrong to the functions

for recent code changes I find myself needing some workarounds for MSVC6: 1st, I need a fast way to swap bytes (for endianness) of a 32-bit int. I could not find a builtin like bswap; the closest thing I found was ntohl() which appears to be a function call and also requires linking with winsock2 (ws2_32.lib) to get it. 2nd, I need an equivalent for lround() (or round() is ok), which is not in

--- configure.ac | 7 +++++ src/libFLAC/bitreader.c | 12 ++------- src/libFLAC/bitwriter.c | 8 ++---- src/libFLAC/fixed.c | 18 +++++-------- src/libFLAC/format.c | 8 ++---- src/libFLAC/include/private/macros.h | 29 ++++++++++++++++++++ src/libFLAC/metadata_iterators.c | 17 +++---------

Erik de Castro Lopo wrote: >> There's the following code in stream_decoder.c: > > Like you, I don't see a lot of value in these. I think I'll decline > these. FLAC__lpc_restore_signal_asm_ia32_mmx compares 'order' argument with 4 and if it's greater then it jumps to FLAC__lpc_restore_signal_asm_ia32. I wonder why the same wasn't done for PPC/Altivec:

Hello Jean-Marc, > Got any luck with the Blackfin stuff? One thing I forgot mentioning that > would probably help a lot in narrowing down the bug is to simply disable > assembly functions one by one and see which one breaks Speex. sorry that I didn't reply for some days. Unfortunately I had some other serious problems with my software which are not related to Speex. I hope to solve

Most asm statements clobber ASTAT bits (shifts, maxes, etc...) but do declare the register as clobbered. Same thing with CC in a few places. Some places make an attempt at clobbering some hardware loop registers, but it's very incomplete compared with how many asm statements actually use hardware loops. Signed-off-by: Mike Frysinger <vapier at gentoo.org> --- libspeex/bfin.h

When using `ssh-keygen` to generate a user key, the default output includes a randomart image. I'm trying to figure out what the usefulness of this image is for user keys. For host keys, the benefit is easily explained, as it makes it easier for a human to ensure the remote host's key has not changed. But for user keys I do not see a use. I know that ssh-keygen is used to generate both

I've just Replaygained several of my Vorbis albums with Vorbisgain, ranging from 80's metal to present day soft rock. What I don't understand is why does Vorbisgain actually make all tracks QUIETER? I see an average of -7db on most albums. And after that, not only are they substantially quieter than my MP3s (which is a pain), but it also fails to really "even out" the volume.

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