similar to: Resampler

Hello Jean-Marc, thank you for your answer! > I'll look into this. There's basically no overflow prevention for now. > I'll think about how to add that without affecting performance too much > (on CPUs that don't have hardware saturation). I'm open to suggestions :-) I'm not sure if I can really help, but I did a few more tests. Reducing the volume of the input

Daniel Schmidt a ?crit : > Hello Jean-Marc, > > thank you for your answer! > >> I'll look into this. There's basically no overflow prevention for now. >> I'll think about how to add that without affecting performance too much >> (on CPUs that don't have hardware saturation). I'm open to >> suggestions :-) > > I'm not sure if I

Hi Jean-Marc, I use the resampler to convert various sampling frequencies to 48 kHz on my Blackfin platform (fixed-point) 48K -> 16K speex -> 48K chain does not sound very good compared to plain 16K. But the main issue is when processing loud signals, I have truncation (and not clipping/saturation) I could hear it and see it with various music and speech messages. See example.png. I also

Hi, I just started to examine the DIV32_16 function (Blackfin ASM version), and wondered why the return value of the function inside 'fixed_bfin.h' is of type 'spx_word16_t', but the local variable 'res' which is returned by this function is of type 'spx_word32_t'. Is this a trick of optimization or a bug? (Same question for PDIV32_16 and MAX16, too!) best

Hi, I tried to figure out what the problem is -- but it seems to be totally different from what I expected. My status at the moment is: - computing results for "generic" and "Blackfin ASM" versions of the DIV32_16 function are the same, there is no "algorithmic bug" - Instead, there seems some sort of memory corruption: When I comment out the DIV32_16 function

Jean-Marc, Frank, I have stumbled across a similar situation regarding optimization. I seem to have a similar setup as Frank does with a fixed 48khz in and out. The wideband mode and ultra-wideband modes are really what I?m looking for. I have a test application that reads audio, downsample to 16kHz (or 32kHz), speex encode, speex decode, upsample back to 48kHz, and playback. If I remove

Hi Jean-Marc, didn't get a reply to my last post (see below) -- do you have no idea what happens here? After some more tests, I disabled the DIV32_16 Blackfin optimizations and now get good quality on the Blackfin. But when I have overdrive on the input, things become very bad -- I'm not sure if this is really a filter stability issue like I wrote some weeks ago. I use the speex

Hi, when I compile with FIXED_DEBUG enabled, I get an error -- both when make tries to build testenc.o and when I try to link my app against the speex lib: lorenz@panelmaker:~/Blackfin/tests/speex_loopthrough$ make bfin-uclinux-gcc -c -g -I/home/lorenz/include -o main.o main.c bfin-uclinux-gcc -gl -elf2flt -L/home/lorenz/lib -o speex_through main.o -lspeex_debug -lspeexdsp -lm

Hi Jean-Marc, after some problems with getting svn to work here I finally made it. Problem is, you write that I cannot use libspeex and libspeexdsp at the same time now -- because I use a "live" system (mic-in -> speex_enc -> speex_dec -> headphone out) and I can run the AD1836 audio codec on 48 kHz only, I cannot use my program now (because I use speex resampling...) So I

> Quoting Stephane Lesage <stephane.lesage at ateis-international.com>: > > Is this a bug ? Is it possible to fix it ? > > (I use version speex 1.2beta2, because newer versions just > don't work > > on my > > platform) > > This is probable the cause. 1.2beta2 was the first release to > include the resampler and it had many bugs. I suggest trying

Hi Jean-Marc, Thanks for taking a look. I've added an example program in the patches that changes the rate frequently. You can run test-resample2 >test.raw and open in audacity or so to look at the spectrum etc. I've attached a before/after screenshot. In theory, depending on the current phase and the rate changes that are applied, the error can be audible as a pop when changing

> -----Message d'origine----- > De : Jean-Marc Valin [mailto:jean-marc.valin at usherbrooke.ca] > Envoy? : dimanche, 14. juin 2009 20:46 > ? : Stephane Lesage > Cc : speex-dev at xiph.org > Objet : Re: [Speex-dev] Resampler saturation > > Just to make sure I understand, the two patches you sent are > two different ways to fix the problem, with the only >

Hi, 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. I find the quality of Speex resampler to be decreasing when I increase the quality q of the resampler init function. Can some one give me pointers regarding this?? As per the API, if the

John, Thanks for the reply! You mentioned output sample rates should be 44100 or 48000, should I worry about input (Mic) Sample rates as well? (Currently I was requesting the sample rate on both ends to be 16000 samplesPerSecond, for ease of passing into the codec) Also, do you recommend any particular resampler that I should use, or are any of the ones out there probably okay, or should

Can someone who really knows the Ogg command-line encoder, help recommend the best setting for 33.6k modem stereo music streaming? (56k doesn't count cuz many people's 56k modems don't work at a full 56k, and I want them to be able to surf CD Baby at the same time as listening. 2 minutes / 120 seconds of audio should be about 400k.) I'm at my wit's end: tried everything I

Hi, These patches improve the resampler set_rate function. The first 2 patches do some cleanups in the GCD calculation and avoid an overflow when calculating the new phase. This patch could probably be simplified if we allowed 64bits operations in speexdsp. The 3rd patch avoid rounding errors in the phase calculation. The problem is that the new rate is calculated with the reduced rate, which

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 ,

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

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

On Sun, 2003-11-23 at 03:51, Kerry Cox wrote: > Hmmm, I guess more is incorrect here than I thought. I changed the > resample in-rate to be 44100 like it should have have been. > But still no joy. Here is the error message as shown in the error.log > file. I'm looking things over and am not seeing my error. > It looks like the audio resample for this particular stream is good.