![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
wolfwingsOkay... if you're reading this, prepare for some techy blabbering.
I've been researching stream-radio solutions that allow for simple transmission from a Line-In or WinAmp instance, preferably with an added Mic-In component on the streaming server to allow for transparent and trivial voice-overs. Preference being given to Ogg Vorbis encodes, as even at stupidly low bit-rates like 12kbps Ogg still sounds listenable. MP3... well, doesn't. And AAC is simply prohibitive to broadcast in due to licensing fees and the like.
Turns out that's pretty much the design-goal of most of the popular software out there. Or at least... it's turned out to be a pretty trivial construction to layer things together to accomplish what I wanted to design. Inaki, you listening? Here's the setup I've tested under Linux on my laptop.
Core server software: IceCast
Supplementary stream client/server software: Ices
Core broadcasting client software: Oddcastv3 available as a WinAmp 2.x/5.x plugin, and a standalone plugin, able to record from Line-In or from the WinAmp stream.![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
djgenki might have some use for the standalone version for example, as he can hook up some turntables then if he was having to use WinAmp before.
Configuration is a multi-stage affair:
One copy of WinAmp running under WINE, running Oddcastv3, broadcasting one ~96kbps stereo 44khz Ogg Vorbis stream to the intermediary IceCast server.
One intermediary Icecast server, listening only to the WINE-wrapped WinAmp session. In effect, demultiplexing the input stream to the local server. Theoretically this could be reconfigured to suck in OggFLAC, but I didn't test that. This is also the ONLY server you need to adjust things like 'station ID' sound clips and the like. It's also the server that everything else actually relies on.
Multiple copies of Ices sucking down the stream from the intermediate Icecast server. 12kbps Mono 8khz Vorbis, 32kbit stereo 44khz Vorbis, 96kbit stereo 44khz Vorbis, specifically. Required using a wget-equivilant program to suck the HTTP stream down to stdin, which was piped directly into Ices.
One IceCast server with all the 'actual' sources on it, listening to the copies of Ices. In my test configuration I had a 12kbps mono 8khz, ~32kbps stereo 44khz, and ~96kbps stereo 44khz Ogg Vorbis Stream being served via loopback. That was 3 sources, 100 listeners limit in the configuration file. Vorbis degrades like analog audio, instead of breaking into harmonic distortions like MP3, so the re-encoded 96kbps->96kbps wasn't that noticable, still superior to a 96kbps MP3 stream I tested later via LAME (one of the best MP3 encoders out there currently). Hell, the 12kbps Vorbis stream could sound better than the 32kbps MP3 stream just because Vorbis degrades more nicely, sounding like a badly-tuned AM station instead of bad digital crumble. This server sucked down the metadata from the first IceCast server which got it from the initial broadcast, no special configuration needed.
One copy of MPlayer actually playing back a live stream from the final IceCast server. I switched between streams, never had a problem.
So...
The DJ only needs one copy of WinAmp, or can just run the Oddcastv3 software standalone package if they want to live-mix or something similair.
The server sucks that down, duplicates the stream, then does all the re-encoding to the target bitrates.
The listener has a wide selection of bitrates to listen to.
And there is no reason the 'raw' DJ stream can't be punted to other icecast servers remotely, to easilly support redundant broadcast sources.
This seems like the most reasonable setup. And the icecast servers can be set up to cross-relay against each other, so a DJ can have multiple choices for shoving their sound into the network if you really want to get fancy.
This idea sound reasonable, Inaki? =^.^=
I'm still researching a good transcoder to support punting out MP3 streams as well, if you're still interested in that? There's license fees similair to AAC for MP3 encoding legally now unfortunately though. :-P
I've been researching stream-radio solutions that allow for simple transmission from a Line-In or WinAmp instance, preferably with an added Mic-In component on the streaming server to allow for transparent and trivial voice-overs. Preference being given to Ogg Vorbis encodes, as even at stupidly low bit-rates like 12kbps Ogg still sounds listenable. MP3... well, doesn't. And AAC is simply prohibitive to broadcast in due to licensing fees and the like.
Turns out that's pretty much the design-goal of most of the popular software out there. Or at least... it's turned out to be a pretty trivial construction to layer things together to accomplish what I wanted to design. Inaki, you listening? Here's the setup I've tested under Linux on my laptop.
Core server software: IceCast
Supplementary stream client/server software: Ices
Core broadcasting client software: Oddcastv3 available as a WinAmp 2.x/5.x plugin, and a standalone plugin, able to record from Line-In or from the WinAmp stream.
djgenki might have some use for the standalone version for example, as he can hook up some turntables then if he was having to use WinAmp before.Configuration is a multi-stage affair:
One copy of WinAmp running under WINE, running Oddcastv3, broadcasting one ~96kbps stereo 44khz Ogg Vorbis stream to the intermediary IceCast server.
One intermediary Icecast server, listening only to the WINE-wrapped WinAmp session. In effect, demultiplexing the input stream to the local server. Theoretically this could be reconfigured to suck in OggFLAC, but I didn't test that. This is also the ONLY server you need to adjust things like 'station ID' sound clips and the like. It's also the server that everything else actually relies on.
Multiple copies of Ices sucking down the stream from the intermediate Icecast server. 12kbps Mono 8khz Vorbis, 32kbit stereo 44khz Vorbis, 96kbit stereo 44khz Vorbis, specifically. Required using a wget-equivilant program to suck the HTTP stream down to stdin, which was piped directly into Ices.
One IceCast server with all the 'actual' sources on it, listening to the copies of Ices. In my test configuration I had a 12kbps mono 8khz, ~32kbps stereo 44khz, and ~96kbps stereo 44khz Ogg Vorbis Stream being served via loopback. That was 3 sources, 100 listeners limit in the configuration file. Vorbis degrades like analog audio, instead of breaking into harmonic distortions like MP3, so the re-encoded 96kbps->96kbps wasn't that noticable, still superior to a 96kbps MP3 stream I tested later via LAME (one of the best MP3 encoders out there currently). Hell, the 12kbps Vorbis stream could sound better than the 32kbps MP3 stream just because Vorbis degrades more nicely, sounding like a badly-tuned AM station instead of bad digital crumble. This server sucked down the metadata from the first IceCast server which got it from the initial broadcast, no special configuration needed.
One copy of MPlayer actually playing back a live stream from the final IceCast server. I switched between streams, never had a problem.
So...
The DJ only needs one copy of WinAmp, or can just run the Oddcastv3 software standalone package if they want to live-mix or something similair.
The server sucks that down, duplicates the stream, then does all the re-encoding to the target bitrates.
The listener has a wide selection of bitrates to listen to.
And there is no reason the 'raw' DJ stream can't be punted to other icecast servers remotely, to easilly support redundant broadcast sources.
This seems like the most reasonable setup. And the icecast servers can be set up to cross-relay against each other, so a DJ can have multiple choices for shoving their sound into the network if you really want to get fancy.
This idea sound reasonable, Inaki? =^.^=
I'm still researching a good transcoder to support punting out MP3 streams as well, if you're still interested in that? There's license fees similair to AAC for MP3 encoding legally now unfortunately though. :-P
(no subject)
Date: 2006-02-04 04:38 pm (UTC)If this could be fixed, I'd be supremely happy!
Huh... I'll look into solutions for that.
Date: 2006-02-05 12:03 am (UTC)Re: Huh... I'll look into solutions for that.
Date: 2006-02-05 02:04 am (UTC)We were having issues where the next DJ would connect, the server would say "sending too fast" and send a wait packet, then the client would start sending 443b packets and never recover.
I DID like Icecast's layering system and multiple mountpoints, as it'd let me pretty much do what I wanted with many instances of Shoutcast.
This requires further expiramentation.
Re: Huh... I'll look into solutions for that.
Date: 2006-02-05 02:23 am (UTC)That, and I just love Icecast's stupid-low resource usage compared to Shoutcast. Their Load Testing Results pages are very informative, especially the head-to-head comparison against Shoutcast when you look at how much of a memory-hug Shoutcast is when you jack up the listener count. =-.-= Shoutcast IS more effecient when dealing with a large number of source streams, but HIGHLY ineffecient when dealing with a large number of actual listeners.
(no subject)
Date: 2006-02-08 05:27 am (UTC)