similar to: stuttering in speex 1.1.11

Hi, In the past somebody posted a patch on the list to choose the SSE at runtime using a function called speex_set_asm. I have been searching the archives, but I could not found that specific post. I noticed the new 1.2beta1 does not include this patch, so I was curious if the person who originally made this patch has made the same modifications to the new 1.2beta1. Greetings Jeroen de

Hi, Ok, what you suggest sound logical to me. Currently, I have done a small trick to prevent this problem. What I did is that whenever windows request a voice packet from me and if I do not have the voice packet, I repeat the previous packet. Hence, all the breaking portion is filled with previous packet. This trick seems to work so far. I am not sure what is the side effect. I think jitter

Hi, I saw there is a new release of speex. What is this SPEEX_PLC_TUNING option for? And is there a more complete list of changes? Because I like to determine if it is interesting to update to 1.1.8 Greetings Jeroen de Kleijn (developer of VoIPerized)

With last Wine the sound stutters. With last from Ubuntu repository (old) 1.0.1, work near the flawless! I use alsa (pulseaudio -> default -> alsa). ... But sometime wow crash. Now I've tried 1.1.10 and 1.1.11 and the the sound stutters. Please fix this problem :( Ubuntu 8.10 x86_64 Q6600 at 3.2GHz X-Meridian 7.1 nVidia 8800 GT 512Mb Zotac AMP!

Hi Jean-Marc, For the residue in the echo_cancel function I pass in a pointer to an array of floats. First I used an array the size of the framesize, but I discovered this causes crashes because the echo_cancel funtion writes framesize+1 floats to the pointer. I find this plus one strange, since almost all things are exactly the framesize. Is this an error in the echo_cancel function or simply

> Ok, what you suggest sound logical to me. Currently, I > have done a small trick to prevent this problem. What > I did is that whenever windows request a voice packet > from me and if I do not have the voice packet, I > repeat the previous packet. Hence, all the breaking > portion is filled with previous packet. This trick > seems to work so far. I am not sure what is the

After one minute of connection the stream from our icecast 1.3.10 server (debian package 1.3.10-2) starts stuttering. And after some stuttering the client is disconnected by the server. The usual client is a windows winamp. The icecast logs shows that the the client is not receiving data fast enough. A small part out the logs is shown below. That the data is not received fast enough is rediculous

: : Try 1.3.8 as well, maybe the updated connect code didn't go in until : : then. : Will do. I'll report back after I've had a chance to compile and set : that version up. Initial tests with v1.3.8beta2 seem to solve the problem. To test, I've added two bogus directory servers to the configuration which it cannot possibly connect to and when it goes to touch, there doesn't

> A good number have id3v2 tags... say 20-30%. Do you find that it's stuttering on id3v2 files? Since those contain data that is counted by the timing code, but not played the the player, that seems a likely suspect. Ie, you'll get _playable_ data too slow. Try a stream with _no_ id3v2 files and see if the problem persists. > > What version of linux? glibc? > > RH 7.2

The only thing that has changed is the winamp version number. My radio streams are unaltered (to the point of the same process connecting to two versions of Winamp). What happens is that I begin to hear skips in the stream. Soon the stream is full on stuttering, as if a square wave was modulating the volume control. Anyone else experience this? ------ Dave Hayes - Consultant - Altadena CA, USA

Dear List, After some googling around without any results, I'm quite puzzled. Since some past update I can't precise, kernel 2.6.164 works fine, however 2.6.194 has some sound problem in my somewhat old and beaten Toshiba laptop. -Audacious plays OK but other applications have problems. -For instance, mplayer acts quirky: when I pause a playing video, sound keeps stuttering endlessly. The

I'm running Icecast v1.3.7 and I've recently noticed there's a direct correlation between a stream "stuttering" and the icecast process having difficulty contacting one or more directory servers. In short, if icecast can't connect to a directory server, then it tends to affect the playback on the stream, such that clients will typically get dropped with message such as

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

Hi, When an audiopacket is received too late I could interpolate this frame. The problem is that I don't know if it is a true bufferloss or just the last audiopacket of a talkspurt. Now my question is if it's harmfull for the audioquality that at the end of the talkspurt one frame is interpolated? Or would this be almost inpossible to hear since the last audiopacket in the talkspurt

I'm running xorg-x11-drv-nouveau-1.0.9-1.fc19.x86_64 and xorg-x11-server- Xorg-1.14.2-9.fc19.x86_64 On the following chipset, the display suffers from "stuttering": 06:00.0 VGA compatible controller: NVIDIA Corporation GT200b [GeForce GTX 285] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Gigabyte Technology Co., Ltd Device 34c9 Control: I/O+ Mem+ BusMaster+

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

I've got an Allwell set-top box (http://www.gctglobal.com/Products/Set_Top_Box/set_top_box_0.html) connected to my entertainment center (stereo + TV) running a 2.4.17 kernel. I'm eagerly looking forward to running Boss Ogg (http://bossogg.sourceforge.net/) on it to play my music collection encoded in FLAC. None of my music files are on the set-top box, they're all on a server

Hi everyone, I just released Speex 1.1.11, which includes lots of bug fixes. Among those, the SSE optimizations have now been fixed and a few minor bugs in the fixed-point and Blackfin ports have been corrected. The echo canceller and packet loss concealment have also been improved. There is more info and project files for compiling Speex on TI DSPs (C5x and C6x). Jean-Marc -------------- next

Le jeudi 03 mars 2005 ? 20:29 +0100, Kleijn, J.S. de a ?crit : > I use the Intel compiler 7.0 , and it doesn't like it Does it have an option to enable C99? Otherwise, if you're aware of another mechanism that allows it to allocate temporary stuff on the stack, I might be able to support it. Jean-Marc > -----Oorspronkelijk bericht----- > Van: Jean-Marc Valin

Hi everyone, As many noticed, I just released 1.0.5 and 1.1.8 over the weekend. There isn't much new in 1.0.5, except that I added all the API changes from 1.1.x so that it's possible to write code that will work with both 1.0.5 and 1.1.8. As for 1.1.8, here are the changes: - Initial TI C5x port: I integrated a patch from Jamey Hicks - Some fixed-point improvements and fixes - Better