similar to: Release Candidate 1 released

Hello Jean-Marc >If you want to do it, I can show you >what functions (there are 2-3) to port. Otherwise I might do it >eventually, but it's not a top priority (there's already an SSE version >though). I would indeed like to know which functions can be used to improve K6-2 performance through 3DNow. Cheers Bjoern D. Rasmussen <p><p><p>>From: Jean-Marc

Jean-Marc, I was wondering if you could add a check to ensure that memory is actually allocated during the nb_encoder_init and sb_encoder_init functions. We have been looking at using Speex on a DSP and noticed that if we didn't allocate a large enough heap space memory segment that the DSP would crash. I would recommend something like: if (!st->stack) fprintf(stderr,"ERROR

At 07:55 PM 3/11/03, Jean-Marc Valin wrote: > > - Only narrowband (8 kHz) Speex is currently supported; not > > wideband. (Unfortunately, the assumption that audio sample rate == 8 kHz > > is riddled throughout the Asterisk code.) > >Perhaps it's still possible to send wideband, while telling Asterisk >it's narrowband (the bit-stream is such that you can decode

> I was wondering if anyone has experimented with Speex's wideband (16kHz) > mode at lower quality settings. In particular I have been using quality 3, > and with wideband input files the resultant frequency spectrum is limited to > about an upper end around 3.5kHz (almost telephony quality bandwidth). Has > anyone tried increasing the spectral bandwidth at the expense of

Hello Jean-Marc, Regarding your question - a little background on the various choices, Fair Quality is 15kbps Speex narrowband, Good Quality is 24kbps Speex narrowband, High Quality is 32kbps ADPCM from HawkVoice and Toll Quality is 64kbps PCM. We also have 10 other codecs within the product including GSM, LPC and others that we currently do not expose. To us, quality is a combination of

> - Only narrowband (8 kHz) Speex is currently supported; not > wideband. (Unfortunately, the assumption that audio sample rate == 8 kHz > is riddled throughout the Asterisk code.) Perhaps it's still possible to send wideband, while telling Asterisk it's narrowband (the bit-stream is such that you can decode a wideband frame even if you think it's narrowband). > - Some

> What is the maximum frame-length that libspeex will produce for narrow, > wide and ultrawide encoding? In normal operation (no in-band side information, like requests, ack, stereo, ...), the max size for a frame is 62 bytes in narrowband, 106 bytes for wideband and 110 bytes for ultra-wideband. Jean-Marc -- Jean-Marc Valin, M.Sc.A. LABORIUS (http://www.gel.usherb.ca/laborius)

Le mer 26/02/2003 à 15:43, Rick Kane a écrit : > I was also wondering if there is a standard set of input sequences people > are using to test Speex. I haven't stumbled upon it/them yet. I've got a few samples at: http://www.speex.org/audio/samples/ Jean-Marc > > -----Original Message----- > > From: owner-speex-dev@xiph.org [mailto:owner-speex-dev@xiph.org]On

Hi Jean-Marc, I thought at quality 3 (wideband) - wb_submode1 that the 4-8k band was not using a codebook table. From the code I can see that some sort of "lsp" encoding is performed. What exactly does this encode? (I assume lsp means line-spectral pairs) The reason I am asking is I'm comparing the "effective" spectral bandwidth of Speex against the

> Hmmm, define working and stable :) By that I mean that you're fine with releasing it with your name on it and not be afraid to get flamed. > <braindump topic="speexcat"> > It began as a merge between speexdec and speexenc from 1.0beta3, > with the encoding/decoding removed, and simply piped in and out from > ogg streams. I never expected it would work joining

> I'm not sure if I should post this question to this list. If not; please > tell me. > Ok, here it comes: > Is the following code correct for compressing audio? The output I get is so > extremely small, but what is more important: if I pass it through zlib, it > gets at least 50% smaller! On regular data, gzip might get a 5% reduction, so I doubt you can get 50% unless

Le jeu 20/02/2003 à 12:21, X-Fixer a écrit : > just to check that I've got everything right. > the encoder allows as input > - mono only Well, there's support for simple stereo (intensity-based) encoding too, but it's probably not necessary to take care of it now. > - 8 or 16 bits as floating point numbers (without scaling to 1.0). > floating-point wavs (IEEE) will

Hi, Speex is getting close to beta4, which I'd like to be feature-complete (or as close as possible). That's why I'd like to ask if anyone here has needs for a feature that hasn't been implemented yet. If so, please let me know. For those interested, here's what's going to be in beta4. First, the VBR code has been greatly improved and now works good with wideband too.

What sould be the capture and playback buffer size in 8,16,32 khz for the Alsa system? Can this also causing latency? In the server side I have: -A thread that reads the input from mic (capture) ands copies to main buffer. -The main loop encodes and sends it to the client ( it's read the data from the main buffer) Client: -A thread for

This works really well for white noise reduction. However what I've noticed was the amplitudes of normal speech samples also get reduced. Is this something by design, or is there a way to automatically recover the original speech sample volumes ? <p>Thanks. <p>Tongbiao <p>-----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@hermes.usherb.ca] Sent:

> I'm about finished developing a QuickTime component that supports Speex > (on > MacOS X and Windows).. As it is now the user can set complexity > (SPEEX_SET_COMPLEXITY) and quality (SPEEX_SET_QUALITY / > SPEEX_SET_VBR_QUALITY) and to wether to use VBR or not. Will these > options > make it possible to produce all combinations of bitrates/qualities? Or > should I

> to speex: *now here comes the more important part, can we build a c++ > component which does what avrelay does? is it practicable to de/encode > 100 streams with a c/c++ speex de/encoder in realtime?* COMMENTS WELCOME At low bit-rate (6-8 kbps) and lowest complexity, it's probably possible to encode 100 streams on a 3 GHz machine (and decoding is cheap), but that's all

Can you do another release of the unstable branch that has everything merged in? The run-time flags for SSE / ASM and your new intrinsics. If you have all the sections written, we will happily test them on windows QA machines. Is there anything in particular that you are looking for in testing? Or just that it works? Aron Rosenberg SightSpeed <p>At 01:17 PM 1/18/2004 -0500, you wrote:

It seems to work ok with the same audible quality as a standard sampling rate. Is there any way to test this? Will superimposing an inverse wave over the origional produce a meaningfull result? Thanks for your time, Ryan de Leeuw <p><p>>Sorry for the delay. I've been doing a couple tests >and what I'd suggest >is encoding using the narrowband (8 kHz normally)

> > OK, so here's a first start. I've translated to intrinsics the asm I > > sent 1-2 days ago. The result is about 5% slower than the pure asm > > approach, so it's not too bad (SSE asm is 2x faster than x87). Note that > > unlike the previous version which had a kludge to work with order 8 > > (required for wideband), this version only works with order