Slashdot Mirror
Icecast 2.0 Released
ArcRiley writes "After 3 years of development and 6 weeks of beta testing, Icecast 2.0 has been officially released! Features include support for both MP3 and Ogg Vorbis, a web administration interface, support for listing in directories (such as dir.xiph.org), and is freely available under the GNU GPL for Linux and Windows."
..would mean 3 years of testing, beta or otherwise. It is after all an open source project...
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
Any idea if there is a better interface for controlling which songs play, yet?
Before, IIRC it could only shuffle through a bunch of files in a directory.
In case, you don't know, Icecast is an audio broadcasting system that streams music in both MP3 and Ogg Vorbis format. It is available under the terms of the GNU GPL. The main home page for the Icecast Project is located here.
Icecast is used mainly for a couple different reasons. If you are like me and work at a radio station, you may want to stream your live audio feed over the Internet. This provides access to listeners who would normally fall outside your nominal broadcasting radius. Or, if you wish to play Internet disc jockey, you can create your own playlist, insert sound bytes and broadcast to the world. This is useful for smaller stations who have limited wattage and who wish to play alternative music or talk radio. Because icecast does not broadcast over radio waves or use limited frequencies, it does not fall under FCC rulings. Anyone can set up an icecast server and begin streaming songs or audio files. This ranges from home use through networked machines or for use in a business environment. There are many stations currently using icecast.
>>esr>>
I'd like to run Icecast in our office relaying to some external streams to utilize bandwidth for many listeners. Unfortunately, Icecast stays connected to the relays even when there are no listeners, which is a waste. I remember earlier versions of Icecast had this feature, but it has now since gone.
for non-pro/home broadcasting to take off, there needs to be an underlying p2p network layer. This is particularly true as live video-streaming becomes more popular. http://www.peercast.org/ exists, but sadly doesn't seem to have been updated for 9 months, and activity in their forum is fairly low.
Does this support non-Vorbis Ogg codecs such as Speex or FLAC?
The wonderful thing about shoutcast is, all you need to really run your own internet radio station is WinAmp, shoutcast software, and a playlist.
Icecast sounds like a good idea, but the part where others have to download a plug-in to hear your stream would sound like too much work to the potential listener.
Only if you have Winamp 3 but why would you?
Winamp 2 and 5 support Icecast 2.0 OOB
http://www.icecast.org/3rdparty.php
Incase anyone cant fig it out, icecast is avialable for debian as "apt-get install icecast-server".
If I wanted easy I wouldnt be an engineer or a patriot.
Gotta love the slashdot effect. 15 comments and the servers down..
I used to run small stations in college, using Shoutcast on both Windows and FreeBSD. Very simple to install and run. I've read the Icecast FAQ, and I'm a bit confused. It says that it's compatible with Shoutcast servers. Does this mean shoutcast.com's listing servers? Has anyone seen how Shoutcast and Icecast compare as far as memory footprint, system usage, bandwidth usage? or are they more or less the same?
Nothing but the finest in meaningless drivel
you need a plugin to send stuff to the server to relay, *not* to listen.
Mirror
that I was somehow annoyed that they declared the old version (1.3.2 or something?) as deprecated long time before releasing 2.0. And the website has been unmaintained for quite a long period of those three years.
Actually I turned off my little community-radio-streaming-project just because ogg support was flaky and administration and monitoring was difficult.
But hey, it is always easy to bitch and not to help hands on.
Maybe now Iwill pick up this thing again..
-silence
Dyslectics of the world, untie!
Apologies; an ill-timed cron job strangled the disk throughput on the web server.
But really, who the Hell reads Slashdot before noon? Jeez people, go sleep. CVS will still be there come dusk...
Monty
.. especially for streaming, since a 64kbps stream sounds as good as a 128kbps mp3 stream, which means more people can listen to it, even on their congested at-work LANs, and if you don't attract more people, then at least you cut your bandwidth bill in half. Other codecs that sound sweet at 64kbps exist (windows media, real, quicktime) but they're not free, so you end up paying more than you save in bandwidth.
And if you go legal with your streams, some licensing authorities (for want of a better word) haven't been clued in to how good ogg sounds at half the bitrate, so they'll give you a sucky-quality discount.
If you want to go legal w.r.t. streaming BigFive content in The Netherlands, I don't recommend it btw. BUMA/Stemra seem to have a process in place that's relatively sane (i.e. flat fee for non-commercial use) but you ALSO have to pay SENA (not that it's not spelled SANE..) who are total fucktards in their pricingstructure (BUMA/Stemra are fucktards as well, but at least the pricing schedules seem doable. Anyway, having investigated the options I decided against it (and no, I don't stream unlicensed either).
SCO employee? Check out the bounty
All icecast 2 betas I tried were missing a vital feature; the ability to flood audio data out at the start of the TCP connection (rather than deliver it at the stream bitrate) -- this is vital because when you take too long delivering the data your stream can die due to filled queues.
For example, there may be temporary packet loss on the network that results in TCP data queueing up at the sending side. Now unless icecast can correct for that rate mismatch, you're consistently behind and eventually the stream dies.
I think they might have now added the fix, which is to step up its send rate from the stream bitrate whenever it has to, i.e. whenever the client falls behind (temporary network glitch). The unfortunate result otherwise is that your streams can die on a flaky network connection, even if the average bandwidth over time is more than enough to handle the audio stream!
Or... let me know, try my stream
. Does it die on you quite quickly after connect?
When OggFile becomes useable support for it will be added to Icecast, whereas we'll have support to stream Flac, Speex, Theora (video), any other Ogg codec available at the time. Also, with OggFile, source clients and media players will be able to support these codec combinations, whereas very few players currently support Speex or Flac streaming now.
Vorbis over RTP is not usable as it is, as vital info regarding decoding header tranmission is missing. Anyway, UDP would be really interesting over a p2p multicast streaming network. MP3 over RTP is quite usable (with RFC3119 type streaming).
Self-advertising: poc (http://www.bl0rg.net/software/poc/) can stream ogg/vorbis over HTTP and mp3 over UDP (RTP, and UDP with FEC) and HTTP.
OggFile could simply add an extra layer of abstraction between Gstreamer (and other multimedia libraries) and the media they access. So, instead of Gstreamer needing specific support for each Ogg codec, it will be able to support just OggFile and let the codecs each be added as plugins to OggFile.
You see, Ogg (.ogg) is just a multimedia container format designed for easily seeking/streaming variable bitrate codecs. Vorbis, Flac, Speex, Theora, etc are Ogg codecs, that is, they were designed specifically to be used with Ogg. That doesn't mean they have to be used with Ogg, nor does it mean that they are the only ones (DivX, for example).
Using the Shoutcast DSP (dunno about Odd or Ice), you can specify the soundcard as your audio source, not Winamp. Then, all you need to do is change your recording source in the windows mixer to "What-U-Hear" (not all sound drivers have support for this). Then you can capture anything that opens a windows wave handle. The quality will probably suffer a bit.
Also OggFile is going to be useful for functions other than encoding/decoding. Having direct access to libogg2 means being able to do things like bitstream manipulations (cutting, pasting, etc) and, of course, Icecast and libshout (neither of which do encoding/decoding, but just stream pacing).
It seems like Gstreamer supporting Ogg codecs directly is a redundency which should be replaced by OggFile, not an argument against OggFile's development.
Media players which support Ogg Theora alpha-2 (Xine and mplayer) already support streaming Ogg video. If you have one of these players compiled with Theora support, try opening it with a url from here.
It always worked properly; you misunderstand how the timing has to work.
When a connection is momentarily interrupted, the streaming server doesn't just stall the timing on the connection; it's still tracking how much data had to go out in a given period of time. The total output at any time will always be up to date. Thus, if the network connection is interrupted momentarily, the data will indeed burst forward to the correct point when connectivity resumes. It's like squeezing off a very stretchy hose for a short time.
The connection is dropped only if connectivity disappears for longer than a certain threshold. Oh, and naturally, if you're trying to listen to a broadband bitstream over a 28.8 modem, you're going to get kicked pretty quickly. The hose only stretches so far, and if it bursts your connection gets dropped. That's not a bug.
Also, a client that falls behind on its own will eventually burst the hose. That's a bug in the client; you won't fall further and further behind unless a) your playback rate is way off or b) your buffering is pooched. It's the client's responsibility to accept data at the rate the streaming server sends it. The streaming server's timing is correct; if something happens to mess with the client timing, the client has to deal with that.
As for 'flooding data at the beginning of a connection', that doesn't really make sense in a system where every client has a configurable, different sized prebuffer.
Monty
You should probably describe more the setup and the situation under which this is happening; networks are finicky beasts and if this is passing over a cablemodem link or DSL or WAN routing, burst loss or bandwidth assymetry or ARP warring could certainly cause it. Or the clock on your PC may be way too slow/fast. It's unlikely WinAmp or XMMS, but there's easy ways to figure that out too.
Slashdot is the wrong place to debug this further, but if this is causing you headaches (it seems it is) and you want to figure it out, drop by #icecast on irc.freenode.net and we'll get it sorted. It might take a few appearances in the channel to be there at a time when there are the right folks to help you out, but you'll definitely catch us without too much effort.
Monty