similar to: [patch] Mac Universal Binaries

Well, I don't quite understand why AC_C_BIGENDIAN and the solution you're proposing is likely to break other big endian machines (the ones that don't have __BIG_ENDIAN__). Can you send a patch that addresses that (i.e. still uses AC_C_BIGENDIAN when it works)? Jean-Marc Peter Grayson a ?crit : > Hi all, > > Speex currently decides endianness at configure-time. This causes

On 5/2/07, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > Well, I don't quite understand why AC_C_BIGENDIAN and the solution > you're proposing is likely to break other big endian machines (the ones > that don't have __BIG_ENDIAN__). Can you send a patch that addresses > that (i.e. still uses AC_C_BIGENDIAN when it works)? It is not that AC_C_BIGENDIAN

> It is not that AC_C_BIGENDIAN does not work. It is that it determines > endianness at configure-time as opposed to compile-time. The process > for building universal binaries on Mac demands that the distinction be > made at compile-time. To enable building universal binaries on Mac in > a single pass, the decision has to be deferred to compile-time. I don't quite see the

Here are a few more patches. Still keeping it easy for now. Again the basis for these patches is dovecot-1.1.7. Patch #6. Solve a cross-compilation endianness issue. Currently, Dovecot assumes that the endianness of the build system is the same as the endianness of the runtime system. This is not necessarily true. We ran into this while compiling for i386 on a ppc machine. The

I guess I should add this to the long list of things Apple has broken that used to work well on NEXTSTEP (the operating system that has been turned into OS X). Now that you mention it, I remember having a problem getting flac to cross-compile in one build step, so I just did the manual lipo glue that you talked about. I assumed it was only because I was too lazy to figure out how to

Did you check it against the trunk in SVN? If it's not applied, and you can hook Jean-Marc up with an email address like yours, I'm sure he will get right on it. :) Tom Mihai Balea <mihai@hates.ms> wrote: > > Hi all, > > Did anything happen to this patch? > It seems to me that it fixes a valid issue, but I'm not an expert. > Anyways, I didn't see

There is a problem in speex_preprocess_ctl. Both speech_prob_start and speech_prob_continue are set to 327.67 for all input values except 0 which results in 0. This is in floating point mode. I think the included patch fixes the problem. Mikael -------------- next part -------------- Index: libspeex/preprocess.c =================================================================== ---

On 26 February 2014 14:44, Robert Lytton <robert at xmos.com> wrote: > This is related to a patch I submitted a little while ago (still pending): > http://llvm-reviews.chandlerc.com/D2760 > > If accepted, would it make this patch (and a others) unnecessary? Hi Robert, It is, but hijacking your patch a little, why not use __ORDER_LITTLE_ENDIAN__? Why do we need to create

Hi Jim, Actually, I don't see anything wrong with the internal structure having a different type than the interface, as long both types are big enough to hold the possible values (in this case 0 and 1). Though, as you pointed out, testenc needs to be fixed to use spx_int32_t instead of int. I'll change that. Jean-Marc Jim Crichton a ?crit : > st->highpass_enabled is typed

If we compare the "common" subdirectory between nbdkit @ 6b4178d0fdfe ("ci: Temporarily disable perl in MacOS", 2023-02-27) and libnbd @ d05cd8f384a7 ("Version 1.15.11.", 2023-02-28), we find differences. We can categorize these differences along two (orthogonal) axes: - Intentional or unintentional. Intentional differences are for example when one of the libnbd

On Fri, Apr 4, 2008 at 12:19 AM, Jean-Marc Valin <jean-marc.valin at usherbrooke.ca> wrote: > Jahn, Ray (R.) a ?crit : > > > Dear Speex codec community: > > > > I am working on conversion of voice files. I could not figure out how to use speexdec.exe 1.2.3 in piped mode in order to avoid the creation of the potentially large intermediate *.wav or *.pcm files. Any

Hi, I tried both the stable and beta versions of the speex source code download on Mac OS 10.4.9. I just do: ./configure make sudo make install Then I added libspeex.a from /usr/local/lib and the headers to my xcode project. My app compiles and I'm able to call all of the speex functions. I copied the example code from the website and tweaked it to include the first 10000 bytes of

Hi everyone, I'm about to release version 1.2-beta1 (which I could have called 1.1.13), which includes many, many changes. It would help if everyone could give the svn version (http://svn.xiph.org/trunk/speex/) a try and see if it works fine. I'll check my email next week when I'm back from some vacations and if nothing bad has been reported, I'll make the release. Have fun,

Daniel Schmidt a ?crit : > I found the cause of the problem. The function shift_timings can > produce overflows in the timing array if the jitter is huge or the > time units are very short. After changing the timing values' type from > spx_int16_t to spx_int32_t it seems to work. Hmm, I always assumed there wouldn't be any overflows. What parameter range are you using that

Hi, I'm moving my "metadata" which accompanies some of the speech packets into the speex bits. However, as usual, I'm a bit confused. The manual (PDF from current SVN), section 5.10 (bottom of page 21) states that: "Finally, applications may define custom in-band messages using mode 13. The size of the message in bytes is encoded with 5 bits, so that the decoder can

JonY wrote: > Looks like there are some missed defines in the test_libFLAC++. Attached > patch fixes that. Good one. Thanks. > Also, wsock32 usage is deprecated, on Win7, wsock32 forwards everything > to ws2_32, suggest changing to -lwsock32 to -lws2_32 in configure.ac. > Additionally, using -lwsock32 on Cygwin is wrong. Fix in config.txt. For that I think I'd prefer to

Hi All, Well, we compiled pre9 on an intel Mac running Tiger and now it does work on the machine. I need to see if that will now work on a PPC mac though. Hopefully it will but I am wondering if there is a way to compile and make a universal binary rsync for the Mac that will run on both, from my PPC Mac. Itried that yesterday with patch -p1 <patches/flags.diff patch -p1

Hi Jean-Marc, I have tested Speex in fixed-point mode on my PC without clicking noise. As I mentioned below, I tested Speex in fixed-point mode running natively on the ARM side of the DaVinci without click noise. I only get the clicking noise when running Speex on the DSP side. For the TI C64+ DSP on the DaVinci processor, the TI-specific switches doesn't do much other than defining the

it seems that this check does not work on solaris #if BYTE_ORDER != LITTLE_ENDIAN #define BYTE_SWAP #endif could you please check that BYTE_SWAP is defined in rijndael.c -m

Hi We are currently embedding a rather large C++ library in R (BioC), and we want some comments on the portability of how we have approach this. First of, we are not really able to do much about the portability of the basic library, which of course is the main question :) We have an approach which seems to work, I just want a bit of feedback on it.... The way we integrate it into R is