similar to: pre-buffering

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

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

Hello! I have two questions regarding SWAT. 1) Where is the logout button? 2) How can I set administrative privileges for a user ? ---------------------------------------------------------------------------------------- And a problem with samba: I run gentoo linux, the test version and since my last upgrade to samba-3.0.23a I can't access my server. Until yesterday WindowsXP from another

I have a line in my kickstart file (ksdevice) # Network information network --bootproto=dhcp --device=eth0 --onboot=on # Default network to boot ksdevice=eth0 # Auto reboot (to being next install faze) reboot However its still poping up and asking me eth0 or eth1 for install? Has this operation changed? Thanks, Jerry

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

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?

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

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

Hi, I've just done some test with my icecast server that is in my LAN... It's really slow comparing to many shoutcast server. The bufferization (32 Ko) take about 3s comparing to 1s for distante servers ! What should I do to improuve this ? Regards, Pascal <p><p><p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage:

On 19/02/02 23:09, Likai Liu shaped the electrons to say: > Ricardo Galli wrote: > >By assigning a timestamp to each packet read from the source socket. I > > think the only sane way to do it. > > great idea. with this implementation, actually you can set a smaller > buffer size, but wait a longer time for recovery. once congestion is > clear, previous "missed"

Here's a very odd question - I don't know if anybody can even begin to answer. I am attempting something very odd and geeky. I set up an icecast Win32 server streaming a 96kbps mp3 stream (using all the latest as of today software, winamp, icecast2 and oddcast v3) so I can listen to it on my cell phone while at work. My phone does GPRS EDGE data at 131kbps-ish, just barely fast enough to

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

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

Hi, I?ve seen that shoutCAST sends data much faster than real time when you connect (for a while I assume, otherwise you?d be travelling to the future:). That?s useful for fast buffering. With icecast I don?t get that behavior, stream downloads at real time. Is there a way to buffer data faster than real time? Maybe a ?seek? feature? I need that because I need to allocate a special large

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 will give a little background... For more than 10 years until now im using Shoutcast 1.9.5/1.9.8 win32 on my machines. "What's working, d'ont touch". Now im changing to ice 2.4.2. The flexibility of the ice is great. but, because of the things that "hidden" from the eye im little bit afraid to make changes that will be dramatic for the listeners. So, for the

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

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

Winamp3 is broken according to some posts here. Try Winamp 2.91 or the latest XMMS. Of course, XMMS requires the xmms-mp3 libraries. Try that and see if it helps. KJ <p>On Fri, 2003-09-12 at 15:56, Jeff Ousley wrote: > Thanks, all, for the pointers. I think I have > everything configured properly, but, something is > obviously still wrong. I'm using Kerry's guide with >