similar to: limit-rate usage

As a stream host selling bandwidth space, we are interested in this change. Currently we need to use software we have written to periodically check if all streams do not exceed the bitrate purchased. If one is found, a manual email is written to them. I'm just wondering if your routines take into account internet congestion where the stream may be uploaded at a slower rate for say 30

Hello Thomas and Karl, thank you for your answer and time. We've tested with several listeners and different connections, using WinAmp and JW Player. For about 15 minutes, everything is ok. After 15-18 minutes, WinAmp starts do blink that "red square" (packet loss or instability), and after about 20 minutes sounds starts to "pop", with small cuts, and then starts to

On 11/06/13 07:16, "Thomas B. R?cker" wrote: > Hi, >> Other datail: all users have always "Lag: 0" on Admin interface > > That doesn't need to be a problem, but without full understanding it's > hard to say. that is just the difference between the latest source offset and client offset, at 0, just like on the main trunk, the listener is at the

Hi, Where is the mount option 'limit-rate' in the current version? I checked in cfgfile.c and in the documentation, no mention. Yet this option did exist at one time: http://lists.xiph.org/pipermail/icecast/2010-October/011703.html http://lists.xiph.org/pipermail/icecast/2009-January/011391.html I try to limit the bitrate of a mount-point, is there another solution? Do you know why this

Hi Paul, Thanks for the quick response! We use the same type of encoder (Sam Cast) both live for both mountpoints on 96 Kb Joint Stereo. it is difficult to see if it is exactly the same. Is there a player that show exactly this? I will check this. We have use the limit-rate in our config. Thats work better for go to play the last fallback-mount file (i test this). See here our part of the

un@dom.de wrote: >>i've also linked the stream into dir.xiph.org for testing, >>it shows up, when i click the link, wmp buffers... :( > > > if someone would like to check: > http://dir.xiph.org/index.php?sgenre=&stype=&search=aporee > (don't care about the content ;) > thx, u. You seem to be streaming at all sorts of different bitrates... I'm

Hello, Thank you for your response. It is on the kh version.. https://github.com/karlheyes/icecast-kh Le sam. 3 nov. 2018 à 21:47, Thomas B. Rücker <thomas at ruecker.fi> a écrit : > Hi, > > On 11/03/2018 07:33 PM, Mickael MONSIEUR wrote: > > Hi, > > Where is the mount option 'limit-rate' in the current version? > > I checked in cfgfile.c and in the

I'm running ices-kh to stream from jack at 64kbps, and also using oggenc (with ecasound via jack) to record the audio to disk at the same time. This is also running at 64kbps. ices is using virtually no cpu (0.0%), but oggenc is using 15-16%. I can't see why there should be such a difference - both are recording the same audio stream in real time at the same bitrate. oggenc is getting its

I'm running ices-kh to stream from jack at 64kbps, and also using oggenc (with ecasound via jack) to record the audio to disk at the same time. This is also running at 64kbps. ices is using virtually no cpu (0.0%), but oggenc is using 15-16%. I can't see why there should be such a difference - both are recording the same audio stream in real time at the same bitrate. oggenc is getting its

> www.shoutcast.com). And - at least with MP3 - there is a *big* > difference in sound quality between 96k & 128k. You might want to compare different encoders. From what I have read, lame and its derivatives are great for 128 and higher, and the fraunhofer is good for sub-128, and Xing is always the worst. YMMV of course. Mark --- >8 ---- List archives:

Leo Currie: > This link might be useful: > http://gonze.com/playlists/playlist-format-survey.html > hi leo, thanks for the link, it's definitely useful. meanwhile i doubt that it's a mime-type problem. i've made some php-scripts with different header and mime-type output, makes no difference. wmp buffers until the doctor comes... xmms plays obviously anything... i've

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks. Please, someone confirm if i'm right. if i'm wrong, please forgive-me. - -------------------------------------------------------------------------------------------------------------- I've developed a little tool to stress test tcp connections.( Sending syn and answer ack-syn ). that simuates a real tcp connection. (

Hi all, I'm very new to audio streaming, so please excuse my ignorance. I'm using icecast2 server and muse source client on gentoo linux. Some mp3 files that I'm streaming exhibit severe static noise, in fact, the noise is present always but is most noticeable for the records that are currently playing, http://24.57.213.147:8000/aha.m3u (I'll keep this alive for a while) I

Hello, I''m having such problem with HFSC with following config: + tc qdisc del dev eth3 root + tc qdisc add dev eth3 root handle 1: hfsc default 2 + tc class add dev eth3 parent 1: classid 1:1 hfsc ls rate 512kbit ul rate 512kbit + tc class add dev eth3 parent 1:1 classid 1:2 hfsc ls rate 2kbit ul rate 400kbit + tc class add dev eth3 parent 1:1 classid 1:3 hfsc ls rate 32kbit ul rate

I want to know speex compression rate. On the speex website,it says" Speex is based on CELP and is designed to compress voice at bitrates ranging from 2 to 44 kbps." Is the original voice at bitrates raning from 2 to 44 kbps,or the compressed voice at bits ranging from 2 to 44 kbps? what is the maxmium compression rate? Thanks a lot! Weiqin Bao -------------- next part -------------- An

Hi! A week ago I had a blocked icecast server because of the open files. I read some posts about the 1024 fd limit but this is not the case. My stations rarely has 300 listeners. From the log I can see that around 3PM I had 7 listeners on a mount and 35 on another one. Then, suddenly the only line written to the log is [2013-02-13 15:59:06] WARN connection/accept_client accept() failed with

Hello everyone, I am very tempted to try and use icecast as the weapon of choice to realize a live audio stream for the radio station I work for. Now, the last time I tried the FreeBSD port of Icecast, it immediately consumed something like 95% CPU time, even without any client connected. I think someone else reported that problem, but I somehow lost track of the issue - has this been

Hi Thomas, I don't know if you like top or bottom quoting. That seems to be a big-little endian thing ;-) So, I will top quote and inline quote. Please see my comments inline, below. Kind regards, Stephan On 02/19/2015 04:18 PM, "Thomas B. R?cker" wrote: > Hi, > > On 02/19/2015 03:07 PM, Stephan Leemburg wrote: >> Hello Icecast-dev, >> >> I am new to

Hello Icecast-dev, I am new to this list. I am working for the NPO, the Dutch Public Broadcasting agency. We do a lot of icecast streaming. We run at least 20 icecast server instances on our media streaming cluster. We ran into an issue that clients which where connecting to our streams seemed to be 'hanging' on the connection setup frequently. The client 'thinks' it is

HTB: class htb 1:40 parent 1:1 leaf 40: prio 3 rate 358Kbit ceil 529Kbit \ burst 6Kb cburst 2260b Sent 145871726 bytes 97293 pkts (dropped 69, overlimits 0) rate 56741bit 37pps backlog 23p lended: 77429 borrowed: 19841 giants: 0 I would like to increase "backlog" because I think that would decrease "dropped". 23 packets of 1500 bytes each is only 34,500 bytes. IMO, there