similar to: 4kbps sounds robotic on TMS320C64

Hi, I'm currently working on the TI DaVinci processor, which has an ARM926 processor and a TMS320C64+ DSP in it. I have been using Speex 6kbps (narrowband, quality=2, complexity=1, perceptual_enh=0) on the DSP C64+ side without any issues; the voice sounds very good for such a low bandwidth requirement. However, recently, I tried out the 4kbps mode (changing quality to 1) on the DSP and it

Jean-Marc, Yes, fixed-point is enabled (#define FIXED_POINT in config.h). I haven't tried anything lower than 4kbps; like I mentioned, 6kbps sounds fine so it's very strange. The only code I changed to get 4kbps was setting quality to 1 so that is the only difference in my test code between using 4kbps and 6kbps. It seems to be in the encoder. On the ARM side, I encoded a 8Khz 16-bit

Hi Jean-Marc, I have tested Speex in fixed-point mode on my PC without clicking noise. As I mentioned below, I tested Speex in fixed-point mode running natively on the ARM side of the DaVinci without click noise. I only get the clicking noise when running Speex on the DSP side. For the TI C64+ DSP on the DaVinci processor, the TI-specific switches doesn't do much other than defining the

Sorry everyone, but I figured it out; it's working now. The problem was in my monoToStereo and stereoToMono functions (the Linux OSS driver on the ARM side only supports stereo so I had to convert it to mono before feeding it to Speex); also I had an alignment issue with my buffers I was using on the DSP side. Thanks Jim/Jean-Marc for your help! Regards, Andy ----- Original Message ----

Hi, I've been trying to get Speex to compile and run on the DSP of TI's new DaVinci System-On-Chip processor, which has both an ARM (ARM926) and a DSP (C64+, based on the C6400). I used the latest code (1.2beta) and followed the example in the speex- 1.2beta1/ti/speex_C64_test trunk to build the Speex library for the DSP. Basically I have a loopback application on the ARM that samples

Thanks Jean-Marc. Is there a Speex trunk for the C64xx I can use? Or do I have to figure what options to turn on (in configure) when building the library? Thanks. Regards, Andy Ngo ----- Original Message ---- From: Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> To: ndno72-speex@yahoo.com Cc: jtrantow@ieee.org; speex-dev@xiph.org Sent: Tuesday, December 5, 2006 2:52:02 PM Subject:

Andy Ngo wrote: > Thanks Jean-Marc. Is there a Speex trunk for the C64xx I can use? Or > do I have to figure what options > to turn on (in configure) when building the library? Thanks. Support is in the main version. Just look at the TI/ directory for extra TI-related stuff. Jean-Marc > Regards, > Andy Ngo > > ----- Original Message ---- > From: Jean-Marc Valin

I am specifically using Celt Wideband (48kHz) over WiFi multicast that naturally leads to lost packets and am trying to minimize the impact to the audio. I implemented PLC but the audio it produces is robotic. Have I implemented PLC correctly? Checking the waveform it is using the previous received waveform to fill in a missing packet but not the full waveform so it has to repeat. Basically,

We have an application that plays a variety of sound files on one leg of a call (generated by a call file). We've been told that the party listening to the audio files intermittantly hears "robotic" sounding audio (on/off during the same call). Anyone have ideas on cause? These calls are on an internal network (lots of network bandwidth), and from a server running 99% idle.

Jerry, Thanks for the response; basically, I need to get just the narrow band working now (maybe use advanced features such as jitter buffer, echo cancellation, VAD, etc in the future); the DSP will do the encode and decode simultaneously as data are available. My main objective is just do a voice application that runs on the ARM side of the DaVinci with the codec running on the DSP side; the

Hi, My company just recently bought a TI DaVinci development board and I'm trying to port Speex to run on it. The TI DaVinci chip has an ARM926 processor and a TMS320C64+ DSP in it. I was able to get Speex somewhat working on a TMS320VC5510 about a year ago but I was wondering is there anything special I need to do to get Speex working on the TMS320C64+ DSP in the DaVinci chip. I

Hi, My company just recently bought a TI DaVinci development board and I'm trying to port Speex to run on it. The TI DaVinci chip has an ARM926 processor and a TMS320C64+ DSP in it. I was able to get Speex somewhat working on a TMS320VC5510 about a year ago but I was wondering is there anything special I need to do to get Speex working on the TMS320C64+ DSP in the DaVinci chip. I

What do you mean by "implement"? You're just using the Opus built-in PLC (passing NULL), right? The PLC generally attempts to find periodicity and replicate it. I guess if your signal isn't periodic it can lead to a repetition that isn't great. It's something that could probably be improved in the PLC. Cheers, Jean-Marc On 08/25/2015 01:21 PM, Scott Boekweg wrote:

Do you need to encode and/or decode? I did some work optimizing the DM642 speex 1.1.11.1 encoder earlier this year. I was able to reduce the narrow band MIPS from approx 30 to 16 using some of the #pragmas and optimizing the functions (Following the BlackFin example.) The project I was working on has been put on hold so I haven't looked at the more recent changes. If you are tight on

Jean-Marc, >> > It's odd that it "almost" works with the fixed_generic.h. The easiest >> > thing would be to gradually replace routines and see which one causes >> > problem. It's most likely (though I'm not 100% sure) that somewhere in >> > the code, I have a 16-bit value that gets sent to a function/macro that >> > expects a

Hi everyone, I'm trying to encode/decode with speex, when I do not, the audio is loud and clear, but when I encode/decode to test audio quality, I get a really poor audio quality and a robotic sound. Here's my init audio method : #define AUDIO_QUALITY 10 - (void) initAudio { try { //SPEEX CONFIG speex_bits_init(&bits_in);

Hi Jean-Marc, Thanks for your response. Given a worst case scenario, what is the "worst case" latency (in terms of Speex frames) that the jitter buffer algorithm will incur? We're trying to determine the worst case hard number. Sorry for unclear question below; what I was trying to ask is that given a worst case latency (which I'm asking in the first question) inherent in

Hi, sorry for the repost again, but does anyone have a code snippet example of how to use the jitter buffer? Regards, Andy ----- Original Message ---- From: Andy Ngo <ndno72-speex@yahoo.com> To: speex-dev@xiph.org Sent: Wednesday, January 10, 2007 8:09:10 PM Subject: [Speex-dev] Sample snippet of how to use jitter buffer Hi, I searched around in the Speex manual and API but

> I was wrong, it is the encoder that is not working, and it stopped working > in build 11103. The log message for this build is "another 640 bytes > removed from the encoder state (using the input data instead of copying it > to st->frame/st->inBuf)". Only nb_celp.c/h are changed in this build. What > I am seeing out of the decoder is an extremely low signal

From: Jyri Sarha <jsarha at ti.com> Semantics of inner_product_single have also been changed to contain the final right shift and saturation so it can also be implemented in the optimal way for the used platform. This change affects fixed point calculations only. I also added a new fixed point macro SATURATE32PSHR(x, shift, a). It does pretty much the same thing as SATURATE32(PSHR32(x,