similar to: Second patch again CVS version

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

> - Configurable prebuffer, in seconds. > > - prebuffering parameter in configurable in > <limits>...<prebuffer>seconds</prebuffer>... We're in the process of redoing some of this. We will prebuffer some etc, so in the end this functionality will be there. I apologize that this patch won't get applied for that reason. > - Created a new function

On Friday 17 January 2003 20:17, Karl Heyes shaped the electrons to say: > I would suggest a slightly different approach. > > Instead of increasing the syscall overhead for all sockets, trapping > for uncommon cases. Try the sock_write_bytes and if that is > continuously having to queue (ie not all data can be sent) then display > the warning, maybe make it a run-time option

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mike, I think you dealing with the development. Almost a year ago I've sent few patches to Jack, several of them are already applied to the current version. I'm back again, and tested the last version. I noticed it isn't as resilient to network congestion as my last patched version (just disconnect the ethernet cable of

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"

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

On 24/02/02 05:02, Jack Moffitt shaped the electrons to say: > > - The server didn't check for the status of the client's socket before > > the unblocking send(). This caused a disconnection at a minimun network > > congestion, causing a broken pipe error (Linux 2.4 behaviour?) in the > > network. I've just added a poll in sock.c.> > Can you send me this

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

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

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?

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

On 19/02/02 18:09, Likai Liu shaped the electrons to say: > >It's partially done in the patch I've sent you, completelly done in my > >current version... I can send you the second patch, you will save some > > work. > > how is the calculation being done? do you extract the bitrate from the > stream data, or do you use a different method? I'd advocate *that*

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

Hi, I am wondering how to draw biplot with the same scales on both plots? For example, if the two plots have much different scales, generally the two x-y's are scaled so that the two plots are sitting in the center automatically. How to disable this? Thanks -- Weiwei Shi, Ph.D Research Scientist GeneGO, Inc. "Did you always know?" "No, I did not. But I believed..."

Hello, I wonder if somebody has an idea what could be a reason behind this error message. I am running wine version installed as rpm for Fedora Core: wine-20041201-1fc3winehq. This actually happens for two games, one of them - fallout. I am able to run some windows apps with sound (flash player). Fallout displays initial screen and then crashes with this error message (apparently when it

I am using only WinAmp 2.x and 5.x It works in WinAmp2.x and 5.x at the college network (T1 line), but not at home with cable modem (even with firewall switched off). It tries to prebuffer over 20 minutes - 5 second burst of music and then quits with message (-2:-11). Again, no problem if using FOOBAR2000, but it would be nice to have it work in WinAmp. Murray Saul <p>Geoff Shang wrote:

Here's yet another ogg123 patch that: 1) Adds a command-line parameter "--prebuffer n" or "-p n" that decodes "n" chunks into the buffer before even forking off the writer thread. 2) Moves the buffer_shutdown call in ogg123.c to its proper place. 3) Doesn't use signals ;) This way, the default behavior is to start playing immediately, while allowing the user

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

2018-01-25 12:20 GMT+01:00 Duncan Murdoch <murdoch.duncan at gmail.com>: > On 25/01/2018 2:57 AM, I?aki ?car wrote: >> >> For what it's worth, this is my workflow: >> >> 1. Get a fork. >> 2. From the master branch, create a new branch called fix-[something]. >> 3. Put together the stuff there, commit, push and open a PR. >> 4. Checkout master