similar to: Speex 1.2beta1: Better, smaller, faster and more

Hi, I have been testing 1.2beta1 fixed point and non fixed point as well as 1.0.5 compiled agains uclibc and run on 150Mhz pentium MMX chip. 1.2 non fixed is fastest 60 seconds encoded in 32 seconds at quality 4 1.0.5 is second with the same file encoding in 39 seconds at quality 4 1.2 fixed is slowest with 60 seconds encoded in 58 seconds at quality 4 Is this as expected? Or am I doing

Hi Jean-Marc, > Can you confirm I'm understanding everything correctly? You encode > with > the same encoder and then decode with either A) blackfin assembly and > fixed-point or B) fixed-point only on Blackfin. Then A) sounds bad and > B) sounds good. If you do the same in narrowband, it sounds OK. Is > that > correct? If that's the case, it's *probably* some

Hello Jean-Marc, > Could you try mixing the encoders and decoders (encode with one > version, > decode with the other) to see whether the problem is in the > encoder, the > decoder or both. I tested that,and the results are: The fixedpoint+blackfin encoder used together with the fixedpoint-only decoder produces an bad sounding file (for all the combinations for quality

Hi all, Currently at work we use a commercial product called "Gnatbox", which, I believe, is a BSD derivative running on a floppy disk. They have a pretty UI and all, but I''d feel much safer/happier with a GNU/Linux box and Shorewall doing the same thing. In fact, I''m doing something very close to this at home using Openwrt and Shorewall on my WRT54G router, but I

Hi, I was testing floating point Opus encoder. But it's calling few functions which are implemented in fixed point . I tried to find corresponding floating point functions in source. But not available. Please help me on this. Vega -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello all, I'm testing the Speex codec for my diploma thesis on a BF-533 Blackfin under uCLinux (2005R3 RC3 release). I successfully compiled the Speex (1.1.11-svn) and I can encode/decode wav-files on my STAMP-board using the speexenc/speexdec sample apps. But I encountered that the decoded file sounds strange/noisy, when compiling with "--enable-blackfin-asm" +

hi ,all: comiple error with speex-1.2beta1 why!!?? make /gcc version error?or other lib needed???? ------------------------------------ [guor@ppe speex-1.2beta1-install]$ make -v GNU Make 3.80 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

On Mon, 2019-05-06 at 15:56 -0700, Philip Reames via llvm-dev wrote: > > > On 5/6/19 2:43 AM, Tim Northover via llvm-dev wrote: > > On Mon, 6 May 2019 at 10:13, James Courtier-Dutton via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > > > Although the above is mentioning bytes, looking at the "/ > > > 8" and "& 0x7" makes

Hmm, what these instructions do? (I know nothing about ARMs; I have some knowlege about x86 assemblers and programming). Cant we use pure standard C++ or Java? Does Speex work with fixedpoint math? (As far as I know Java on 6600 has no builtin floatingpoint, there is emulation class somewhere on the net, but it is probably painfully slow.) I do not know if this processor has builtin

Greetings everyone, I was about to compare AEC performance between 1.1.12 and 1.2beta1 when I noticed something. If I configure (and compile) speex-1.1.12 with ./configure --enable-shared=no --enable-static=yes it compiles and works as expected: I can run a mic and speaker signal through testecho, it runs in a reasonable amount of time (about 23 secs for 3 minutes of audio) and I get back

On Thu, 2005-01-13 at 12:42 -0500, Jean-Marc Valin wrote: > Le jeudi 13 janvier 2005 ? 10:59 -0500, Jared Whitby a ?crit : > > Interestingly enough.. I started playing around with preprocessing > > options in 1.1.6 and happened upon the denoise filter > > (SPEEX_PREPROCESS_SET_DENOISE). When i run the test tone using that > > option it is completely filtered out and I

I am running speex 1.2beta1 on WM2003 using FIXED_POINT option, I got big clicking noise during encoding or decoding randomly, I got more noise if I spoke louder or made the MIC sensitivity higher, for example, when I encode the wav file to spx file, the original saved wav file does not have such noise, the noise is added only after it's converted to spx format. The floating point version of

Hi, I saw earlier correspondence (e.g. http://www.xiph.org/archives/vorbis-dev/200202/0131.html) on this list about porting the Ogg Vorbis libs to Symiban EPOC. I'm wondering if anyone really succeeded in doing this, and would share his experiences with me. Thanks, <p>Akos --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/

I'll try to make some shorter samples later, but for now here are the ones I have tried with: http://www.surfnonstop.com/~bandit/speex/1.2beta1_AEC_garble/ The original recordings are in mic.raw and spk.raw. Jean-Marc Valin wrote: > You may have triggered an instability problem. Can you upload your files > somewhere so I can have a look at them? > > Jean-Marc > > Andras

Dear List, I am attempting to perform a harmonic analysis on a time series of snow depth, in which the annual curve is essentially asymmetric (i.e. snow accumulates slowly over time, and the subsequent melt occurs relatively rapidly). I am trying to fit a curve to the data, however, the actual frequency is unknown. I have been trying to follow the methods in Peter Bloomfields text

Hi Folks, I am having trouble using speex_echo_cancel. As a starting point, I am using the testecho.c source code. I compiled the 1.2beta1 version. I have not tried any other versions of speex. The document says that the order of arguments to Speex_echo_cancel is (echo_state, input_frame, echo_frame, output_frame, residue) where "input_frame" is as captured from mic and

Hello, has anyone seen or created a Debian Sarge package for 1.2beta1? I saw some for Sid, but I prefer not upgrading glibc right now, as this is a production server (Asterisk on it will be for testing). Thanks, Juraj.

I had originally mentioned this only to 2 people, which was Jordan K. Hubbard and Paul Henning-Kemp, but since I have received a lot of queries on this, I thought I might as well post it on the FreeBSD announce groups. Included below is a posting done on the Linux-atm mailing group, by Pragnesh Sampat. I have just adapted for FreeBSD. RV -------------------------- Announcement

Dear all, Before I can get into serious Fourier analysis of Radon time-series I am practising with 24hour and 24.8hour sinusoids to assist with my interpretation of signals ittributed to tidal input to Radon time series. I am stuck. I have tried researching this to no avail. I am awating a book that should describe fourier transforms in detail and another one that should discuss the R

*From: *JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> *Date: *Thu, May 9, 2019 at 1:30 PM *To: *Jesper Antonsson *Cc: *dag at cray.com, llvm-dev at lists.llvm.org I don’t think you have consensus to move forward at this point in time. My > expectation, which I think represents LLVM’s historical approach, is that a > path to full support be planned out before this effort starts.