similar to: FW: Handling allocation failure in resampler init - patch

How much latency are we talking about? It seems that this issue cannot be easily pinpointed, but if it turns out to be related to the Speex Resampler let me know and I will put it on my task list. - Sherief -----Original Message----- From: speex-dev-bounces at xiph.org [mailto:speex-dev-bounces at xiph.org] On Behalf Of Colin Guthrie Sent: Monday, December 06, 2010 9:47 AM To: speex-dev at

Hi, I've noticed that the opus-tools is using a really old version of Speex's resampler code - a version that I've seen fail in the wild first-hand under low resource circumstances. I've actually submitted patches for some issues in the Speex resampler a while ago (and IIRC they were accepted): http://lists.xiph.org/pipermail/speex-dev/2009-November/007541.html ,

On 30 April 2010 11:43, Sherief N. Farouk <sherief at mganin.com> wrote: >>> I'm a software engineer. I'm terribly uncomfortable with C. > > Aaaaahahahahahahahaha Please be civil, guys. Different engineers have different skill levels, so what. If someone asks for some help with the reference implementation the least we can do is point them in a useful direction. If

'Twas brillig, and Sherief N. Farouk at 06/12/10 14:29 did gyre and gimble: > If you can produce a simple minimal repro that exhibits this issue on some > procedural signal (sine wave, etc) I'd love to look into it some more - I'm > maintaining a hardened version of the Speex Resampler and would be very > concerned if this bug made it into production. Well at present,

'Twas brillig, and Colin Guthrie at 06/12/10 15:10 did gyre and gimble: > 'Twas brillig, and Sherief N. Farouk at 06/12/10 14:52 did gyre and gimble: >> How much latency are we talking about? It seems that this issue cannot be >> easily pinpointed, but if it turns out to be related to the Speex Resampler >> let me know and I will put it on my task list. > > Will

If you can produce a simple minimal repro that exhibits this issue on some procedural signal (sine wave, etc) I'd love to look into it some more - I'm maintaining a hardened version of the Speex Resampler and would be very concerned if this bug made it into production. - Sherief -----Original Message----- From: speex-dev-bounces at xiph.org [mailto:speex-dev-bounces at xiph.org] On

I'm trying to build the sources from the svn trunk using VC2008, and I'm running into some problems. First, I have no idea what the configure project is for, and it fails with a manifest related error (the project lacks any .c* files anyway). This causes an avalanche of problems, initiated by TableGen not being able to build. Has anyone been successful in getting the LLVM libs to build

On Mon, 2008-09-29 at 15:03 -0400, Sherief N. Farouk wrote: > Why not add types with explicit endianess?... The issues with architecture dependency are far broader than byte order. LLVM in its current form is simply not intended to be machine neutral. Quite the contrary: it is heavily machine dependent!

Le 27 mai 2010 à 08:48, Kevin Wooten a écrit : > This is certainly an option... but keeping up an LLVM backend for the 360 seems like a bit much work. Using Clang's rewriter requires no real low-level maintenance, just creating and maintaining a C library for support functions emitted by the compiler (e.g. objc_msgSend). > The clang rewriter is not the same than LLVM C backend.

This is certainly an option... but keeping up an LLVM backend for the 360 seems like a bit much work. Using Clang's rewriter requires no real low-level maintenance, just creating and maintaining a C library for support functions emitted by the compiler (e.g. objc_msgSend). It seems to create a backend for LLVM targeting the 360 I wouldn't need to create something that outputs XEX's

> hton and ntoh intrinsics. These are needed to allow target code to > deal with endianness in a target independent way. (Ok, you could > potentially write code that detected endiannes at runtime and chose > multiversioned code based on that, but that is ugly and optimization > prohibiting). > Why not add types with explicit endianess? A trick I use for reading binary files

Yep... I have been a 360 developer since the days when it was a actual Macintosh G5. I went to all the early tech. seminars and learned way more about that wacky processor and MS's seemingly crazy ABI choices than I care to (I know, I know, they had their reasons for them). Knowing this is why I quickly turned toward rewriting objc instead of attempting to implement a backend. I have also

I'm a software engineer. I'm terribly uncomfortable with C. I want someone to show me a simplified use of Speex decoding. FWIW I'm finally getting my head around the API but the example had me a little lost with its cryptic variable names and monolithic nature. The example I'm asking for is way simpler than the final code I will ship to production so in essence, I'm looking for

Just to be clear, nothing in the MS TCRs require that you use a certain compiler - it does, however, require that you link with the 360-specific C runtime libraries. That being said, I still believe that direct binary generation is not a feasible option, and the ObjC => C route is preferred. Kevin, hate to be asking this but do you have access to the XDK or are you just "aiming" for

Hi, Here's a patch that allows update_filter() to report errors to its caller. I intend to update call sites to handle update_filter() failures in a future patch, but this one lays the foundation for it. - Sherief -------------- next part -------------- An HTML attachment was scrubbed... URL:

> I could add that to my CMake build system TODO, but so far I'm a bit > skeptic about LLVM relevance on the non-Unix world. The Windows build > can be broken for a long period before anyone notices. The VS2003 > support is broken since a long time ago and, apart from myself, no > other > user cares. Seems that LLVM penetration on Windows, for instance, is > almost nil. Is

Premkiran Mannava a ?crit : > I just built a sample application with speex resampler in linux and I > tried to resample 8K sine wave tone mono to 48k using > speex_resample_process_int. I am using a tool called EAQUAL for audio > quality. That's in general not very reliable. You can get PEAQ to say all sorts of silly things. > I find the quality of Speex resampler to be

Hello. As you probably know, PulseAudio uses the resampler from libspeexdsp by default. As a PulseAudio contributor, I have a feature request. As you can see from old publications [1,2] by Lennart Poettering, PulseAudio has a "timer-based scheduling" feature which is now active by default. PulseAudio attempts to use as high latency as possible (sometimes up to 2 seconds) in order

On 5/29/08, Thorvald Natvig <thorvald at natvig.com> wrote: > Alexander Chemeris wrote: > > On 5/29/08, Thorvald Natvig <thorvald at natvig.com> wrote: > > > I've done listening tests when converting wb_male.wav to 44.1, 48 and 8khz, > > > and there aren't any obvious artifacts. I also did a 16=>16 test, and the > > > results are delayed

Frank Lorenz a ?crit : > And yes, the same "overflow" happens even when I disable Blackfin ASM > optimizations. Indeed, that shouldn't happen. Just to make sure I understand, so far there's two problems: 1) DIV32_16() in Blackfin assembly causes problems 2) The resampler overflows When you fix/workaround those two, is the encoder/decoder working correctly or are there