There appears no source buffering in Icecast 2.0. Please correct me if I'm wrong -- my C skills are a bit rusty -- it looks like apart from a tiny 4K buffer, there is no buffering done when relaying a source. Is this an explicit design decision? The Internet being what it is, unreliable and all, it seems harsh to drop a source that's even slightly lagging, when a bit of buffering could smooth over the bumps. My reading of the code was actually prompted by experiencing frequent disconnects on an international relay link. Am I correct in my analysis? --Renaud --- >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-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Friday 20 February 2004 10:09, Renaud Waldura wrote:> My email has gone without an answer. Is it because:Sorry, I was going to respond to this, but I've been busy and it got dropped to the bottom of a long list of things to do. Yes, there's no source buffering. The design is such that it shouldn't be required. Icecast just sends incoming data on to the clients as fast as it recieves it - this works fine, so long as the eventual/final client has some buffering (they all do). A relay won't get dropped unless it's a long way behind - because on the sending side, there IS buffering. Mike --- >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-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
My email has gone without an answer. Is it because: 1- this is such a stoopid question I should be ashamed of myself -- RTFM 2- this is a well-known issue that everybody's aware of, it doesn't need further discussion thank you, as it is actively being worked on 3- it is meant to be that way and will not change. <p><p>----- Original Message ----- From: "Renaud Waldura" <renaud+icecast@waldura.org> To: <icecast-dev@xiph.org> Sent: Tuesday, February 17, 2004 5:50 PM Subject: [icecast-dev] No source buffering <p>> There appears no source buffering in Icecast 2.0. Please correct me if I'm> wrong -- my C skills are a bit rusty -- it looks like apart from a tiny 4K > buffer, there is no buffering done when relaying a source. > > Is this an explicit design decision? The Internet being what it is, > unreliable and all, it seems harsh to drop a source that's even slightly > lagging, when a bit of buffering could smooth over the bumps. > > My reading of the code was actually prompted by experiencing frequent > disconnects on an international relay link. Am I correct in my analysis? > > --Renaud > > --- >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-dev-request@xiph.org'> containing only the word 'unsubscribe' in the body. No subject is needed. > Unsubscribe messages sent to the list will be ignored/filtered. >--- >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-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Friday 20 February 2004 00:09, Renaud Waldura shaped the electrons to shout:> 1- this is such a stoopid question I should be ashamed of myself -- > RTFM > > 2- this is a well-known issue that everybody's aware of, it doesn't > need further discussion thank you, as it is actively being worked on > > 3- it is meant to be that way and will not change.No, if you search old archives (almost two years ago, http://breu.bulma.net/?l2480) you will see I've sent patches for server buffering (fast start) and other things that were never included. You can check the difference with http://mcrg.uib.es:8000/live.ogg which run my code realiable for more than a year now. The server also had a remote DoS bug, I sent the patch also and it was not included, I did not receive any answer neither, so I just stopped. -- ricardo galli GPG id C8114D34 http://mnm.uib.es/~gallir/ Recursivo. (del lat. recursus), adj. CondiciĆ³n de recursivo. --- >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-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.