similar to: How improuve bufferization speed ?

What is the best way to pick a prebuffering length for a streaming audio application using UDP transport? I'm using Speex in a VoIP application with RTP transport, currently with a fixed 500ms prebuffer on the playback side. However, I'd like something a bit more adaptive to accomodate high-jitter connections. For example, in one test configuration there is a very low average

Ok, this is a silly question, but what does the jitter buffer do? I'm really new to audio, so please bear with me. From what I gather (primarily from the list archive), the jitter buffer is a wrapper around the Speex decoder. I give it the packets I receive, in whatever order I receive them, and then it gives me back a clean stream of audio samples. But what I don't entirely

Hrm, yes it does sound like a bug in WinAmp. Even if it does prebuffer, the length counter should be going beyond 0:01 since you've obviously been listening longer than that after the first second. =P (I don't think the counter resets after buffering, but I could be wrong.) Can you see if you can duplicate it by getting someone else to tune in to the 'cast with WinAmp?

On 19/02/02 03:06, Jack Moffitt shaped the electrons to say: > > The point is, is this list related to icecast2 development? I made some > > changes to the server and sent a patch to Jack Moffitt, but I'm not sure > > he's still mainaining the server. > > You're in the right place, and I still maintain the server. I don't > remember your patch right

Noticing a strange issue, i'm not sure where this lies. I'm using oddcastDSP to stream Ogg to icecast2, which seems to be working ok, but using winamp (v2) to stream from icecast, winamp is constantly prebuffering, displaying a length of 0:01. Is this a known bug in either Winamp or icecast, or a configuration issue perhaps? I have a feeling this is Winamp, but I was wondering if anyone

Sounds like WinAmp isn't storing a large enough buffer, or Icecast isn't putting a long enough buffer between what it recieves from Oddcast & what it transmits to clients. I've never had such a problem, though. Could be your connection? >===== Original Message From John Farnsworth <si@darkness.nu> ===== >Hrm, but it works fine (and the mountpoint is /dnumusic.ogg).

Ah, I'm sorry, I have read the manual and believe I have a reasonably good grasp on how to use the Speex encoder and decoder altogether. In fact I've been using it with great success in my P2P SIP/RTP VoIP application for almost a year now; it's been working wonderfully and I can't thank you enough. However, the manual makes no mention of the jitter buffer, nor does it (so

Hi, How can I broadcast the same source in 128 kbps, 64 kbps and 24 kbps ? Regards -- EISELE Pascal <lemmingsml@nerim.fr> --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject

Hi all, I am ricardo galli, I've juscribed just a couple of days ago. I wanted to stay as a lurker for a longer period, but this list has almost no traffic, so I wake up due to the silence. The point is, is this list related to icecast2 development? I made some changes to the server and sent a patch to Jack Moffitt, but I'm not sure he's still mainaining the server. If he

I send a patch again the last CVS version. The changes are: - Configurable prebuffer, in seconds. - prebuffering parameter in configurable in <limits>...<prebuffer>seconds</prebuffer>... - Created a new function (send_client_queue) to send the client->queue. Better modularisation. - Moved queue_lenght verification to send_client_queue(). - instead of disconnecting when

also, you can try two more things: 1- make the mix by hardware: a very simple mix console can do that. you can build it starting from resistors and capacitors. You can find a lot of such circuits in google. 2- mixing by soft: I can't tell you right now which soft can do that, but may be you find someone. chao, karel --- Geoff Shang <gshang@uq.net.au> wrote: > Hi: > >

Hi, Just wanted to clarify, can icecast2 not read OR broadcast any mp3, or can it just not broadcast mp3 (but still play from a playlist)? I know the quality would be dropped if it had to reencode them though. And what's up with that POS Winamp3, it doesn't even play gg streams?!? I use xmms, but we have winamp3 on a demo computer, it just sits and keeps prebuffering. I need something

We're running a setup with M3W on a PC in Sri Lanka, encoding to a server in the UK. What factors govern the time delay between things being said to the microphone in SL and heard by a client connecting to the server, and how can we reduce it as much as possible? Currently we're experiencing 20-30 secs or more.

> > Is it true ? And if it is, is there any way to change that behavior ? > > Yes. Icecast always sends data at the data rate. This behavior will > not change in the 1.3.x branch. We will however try and make > prebuffering as fast as possible in 2.x (it's currently done the same > way, but we plan to add this feature). Doesn't icecast send the data out as fast as

Greetings, I am trying to track down a bug with intermittant glitching in our Vorbis streams. I am running Icecast 2.3.2 on Ubuntu 9.04. Several Vorbis clients seem to glitch on some (not all) metadata updates. As we update metadata 3 to 4 times a minute, this is something we are trying to fix, VLC gives the following output on metadata update: main warning: the mixer got a packet in

Dear Group, I'm running the following setup; Yoper v2, Kernel 2.6.8.1-7, Wine 20040914 on a Toshiba Satellite Pro 4600. The Toshiba has a Yamaha AC-XG. In addition I have a USB Plantronics DSP100. After some tweaking I got wine to install x-ten lite; I have pasted my config file; [WinMM] ; Wine supports the following sound drivers: ; winearts.drv ; for KDE ; winealsa.drv ; for

I'm trying to set up a live stream originating from line-in on my soundcard. I'm attempting to use Icecast2 and Ices2. I've been up and down the configuration. I switched from the line-in method to using .ogg files as source. These .ogg files play find independent of Ices2/Icecast2. Ices2 and Icecast2 are running on the same Redhat 9 machine. In both cases, Winamp appears to

I'm rather new to this. I just set up Icecast and Ices using source from CVS downloaded yesterday (3-20-2003). The box is running RedHat 8.0 with all the required RPMs to compile. Here's my trouble: I have Ices running in live mode, with it connecting correctly to the Icecast server on port 8000 (which is only bound to 127.0.0.1). I'm using Winamp on the client end connecting to port

I know you're tired of hearing me complain about ogg123, but this time I noticed that some of the error messages are a bit inconsistant. Also, I noticed that some things (like "Error connecting to server") are fatal errors that kill ogg123, while I think they should simply go on to the next file in the list like "input not an Ogg Vorbis audio stream" does. Another problem

Somebody knows how do I set wineoss.drv or winealsa.drv to use the second sound card instead of the first one? Currently I'm using winearts.drv, but want to get rid of arts, cause wine is the only one on my box using it. Thanks.