similar to: Range of Speex input samples

Speex 1.2beta1 announcement: This new release brings many significant improvements. The quality has been improved, both at the encoder level and the decoder level. These include enhancer improvements (now on by default), input/output high-pass filters, as well as fixing minor regressions in previous 1.1.x releases. A strange and rare instability problem with pure sinusoids has also been fixed. On

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

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

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

Hi Steve, Steve Kann wrote: > Chris Flerackers wrote: >> 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

>> 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

Jean-Marc Valin wrote: > 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

> Page 3: > > To be compliant with this specification, implementations MUST support > 8 kHz sampling rate (narrowband)" and SHOULD support 8 kbps bitrate. > The sampling rate MUST be 8, 16 or 32 kHz. > > There is a type above after (narrowband), there is a " extra character. > > I don't understand what is the motivation to specify "SHOULD

Hi, Sorry if this a repost but I want to create the smallest Speex library possible to be put in TI's TMS320 DSP. I'm only interested in one configuration: 5.97 Kbps narrowband. What part of source code can I remove? Currently, when I compiled the version 1.1.12 libspeex.a library with the TI TMS320 and Fixed-Integer options, I get around 522Kb. I would like to reduce it to as small

Hi all, Accoring to the Table.8.1 and Table.8.2 of speex manual (Version 1.2 Beta 2), the data rates supported by speex codec for narrowband are 3.95, 5,95 ,8 ,11 ,15 ,18.2 and 24.6kbps. But when I run the code(downloaded from www.speex.org), I am getting data rates of 4,6,8,11.2,15,2,18.4 and 24.8 kbps. That is, for an input of 20ms frame the number of output bits I am getting are

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

Hello to all speex developers, I have question regarding payload length of narrowband speex in RTP. I were watching tcpdump of the xlite softphone and have found that it uses weird payload length namely 75 Bytes I went through various source and without success. To be clear: For 8000Hz sample in 20 ms that is 160 samples per frame. This makes 50 frames per sec. modes bit-rate 8 kbit/s

--- Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > > Sorry if this a repost but I want to create the > > smallest Speex library possible to be put in TI's > > TMS320 DSP. I'm only interested in one > configuration: > > 5.97 Kbps narrowband. What part of source code > can I > > remove? Currently, when I compiled the version >

I always assumed that ov_read_float() would get me samples in the range of [-1,1), and anything below or above that can be clamped (or clipped in the final conversion to an integer format.) However, I recently saw this: https://github.com/LaurentGomila/SFML/issues/310#issuecomment-9974550 Apparently, there are Vorbis streams that use float samples with values in the range of [-32768,

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 -

Le mar 11/11/2003 à 05:00, MAL a écrit : > Jean-Marc Valin wrote: > > 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

>> The main idea is that Speex supports many bit-rates, but for one reason >> or another, some modes may be left out in implementations (e.g. for RAM >> or network reasons). What we're saying here is that you should make an >> effoft to at least support (and offer) the 8 kbps mode to maximise >> compatibility. > > I understood this. But as you may know: the

Hi Jean-Marc, We already decided to use Marvell's 88F8618 platform, But I have few questions to you and listed it below, Q1, Can we implement the Speex Codec on Marvell 8618 for non-HW DSP of platform? Q2, Based on ARM9 CPU core, do you have any information to let me estimation the voice computing power for Speex codec? Sorry to bother your job again.... Best Regards Janus ( Freedom )

Hello, thank you for responding. I'm sure I'm confusing something, but I did not explicitly set either kHz or kbps, I just set the mode to narrowband, and traced through libspeex's code to see that sample_rate was 8000 something, I'm guessing Hz. My assumption was: if you set PA to nb-mode, then you should encode 160 bytes to 21. Is that mistaken? ys On 6/13/07, Jean-Marc Valin

Hi, I am using speex 1.2beta2 on a narrowband 16-bit, 8khz system that has a severe program space problem and will not fit speex in its normal operation. In an attempt to shrink speex I placed a breakpoint in every function and ran a decode and encode and removed the breakpoints that I hit. in the functions that had a breakpoint that I didn't hit I commented out those functions (as well as