similar to: delay issues in speex, integer API

Le mar 18/11/2003 à 17:39, Allen Drennan a écrit : > Speaking of video conferencing in conjunction with Speex, we are > currently beta testing a solution we developed that offers multi-point, > multi-party video and audio using the Speex engine for voice. > > http://www.wiredred.com/downloads/ecsetup.exe > > The fair and good audio settings are Speex narrowband, high quality

FYI, the Asterisk software PBX <http://www.asterisk.org/> has now incorporated my recent patches to support dynamic RTP payload types. As a consequence, its SIP implementation now supports Speex, so if you have a Speex-compatible SIP client, you can use it to make calls using Asterisk. Some caveats: - Only narrowband (8 kHz) Speex is currently supported; not wideband. (Unfortunately,

I saw a thread in the list archives about a speex port to TI 55x DSP. Wondering how that worked out (is working out)? Also wondering if there is a source archive for it, or if the patch in the email archives is still current, or if there's been updates. Any info appreciated. Thanks Paul

Peter Saint-Andre a ?crit : > Ivo Emanuel Gon?alves wrote: >> Just a heads-up, I received confirmation that Speex is now the default >> codec for the Jabber's Jingle VoIP protocol. > > Which we hope to finalize soon for broader adoption. :) That's good to hear. Are you supporting wideband or just narrowband? Jean-Marc

> The mode/bit-rate is detected automatically by the decoder because it's > encoded in the first few bits of each frame. The encoder can change > bit-rate at any time without telling the decoder. Can you be more > precise as to what isn't clear? I think that one got me too. If mode is detected automatically by the decoder, what is the purpose of the 'mode' parameter

In a "normal" frame that doesn't have in-band signalling (which nobody seems to use anyway), the frame starts with the narrowband information. If the frame is in wideband, then this will be followed by a bit of wideband information that starts with a bit set to 1 (narrowband starts with a bit set to 0). Have a look at what the Speex decoder does. You may actually want to have similar

Hi, I just released unstable version 1.1.2 that contains more fixed-point work. Though it's still not 100% complete, enough have been done to make it run in real-time on ARM. In order to do that, compile with --enable-fixed-point --enable-arm-asm. All narrowband modes work in real-time with complexity 1 (some work with higher complexity) and some wideband modes also work (up to ~20 kbps) at

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

Hello I'm working about audio and video codecs. I'm making a research about the state-of-the-art in coding technologies. My question is about the speex codec 1.0. I would like to know the name of the algorithms that it uses.(LPC,CELP..). It uses more or less the same algorithm for narrowband and wideband? Finally i would like to ask about future codec developement projects. Thanks

Compared to todays PDAs the GameBoy Advance (GBA) is low spec. it has a 16MHz ARM7tdmi RISC processor. 32-bit but it can handle 16-bit instructions in a mode that resembles "bytecode" (a 32-bit instruction is executed using a 16-bit instruction). I got a feeling that the GBA would need a FPU. For more information on the GBA visit this info page:

Hi, 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 lowering the

On Wed, 6 Dec 2006, lianghu xu wrote: > Hi Jean-Marc, > > I remember you said that the SDP tells the mode information. Right. But a decoder like speex can always be configured from information contained in the incoming stream. That makes your application more interroperable. Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 -

Hi, Just to let you know that Speex 1.0 RC3 is out. It should be the last RC until 1.0 is released (tentative release date is March 16th). Please give RC3 a try and report bugs so they can be fixed before 1.0. As usual, download from http://www.speex.org/download.html Jean-Marc -- Jean-Marc Valin, M.Sc.A. LABORIUS (http://www.gel.usherb.ca/laborius) Université de Sherbrooke, Québec,

It looks like I'll need to go further into the guts of speex to do this. I do, however, see some lines in nb_celp.c/nb_decode() that look interesting. I guess I'll play with it. I doubt that it will be terribly clean, though. Jean-Marc: Take a look at line 1195 in nb_celp.c (CVS). It reads "speex_warning ("More than to wideband layers found: corrupted

Hi, 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 also use

>> Consider a device that only has enough ROM to store one set of >> quantization tables (the limitation could also be about speed, network, >> ...). If you specify MUST be able to decode, then it means that this >> device simply *cannot* implement the spec *at all*. This is bad for >> interoperability. > > For me: device which don't have all mode

Hi, Is there an easy way to get the size in samples of a Speex packet, without decoding the packet? If I receive a "narrowband packet" with - Zero or more wideband frames (must be skipped apparently) - Zero or more Speex inband requests - Zero or more user inband requests - One or more narrowband frames I need to know how much samples the packet contains to calculate jitter buffer

Hi Reed, I've been using Speex to transmit TTS for years. It works very well with no tweaking. I use Microsoft TTS ("Microsoft Mike") with Speex at 16kHz wideband and VBR quality 6. Sometimes I forget that the sound is even coming from another computer and being compressed+decompressed. If anything, TTS seems easier for Speex to deal with than real voice. But I don't

Do not forget to add the "Copying conditions" to the RFC. Check http://wiki.debian.org/NonFreeIETFDocuments That page contains a section titled "Template for RFC authors to release additional rights". To follow that guideline a section like the following should be added: x. Copying conditions The author(s) agree to grant third parties the irrevocable right to

> Another issue is the memory allocations distributed so many places that > it's hard to provide a single memory initial function interface. > > In a VoIP case on ARM, the total memory size for speex codec should be > known at the inital stage since all the memories are allocated > at the initial stage. If you want everything in the same big block, all you need to do is