<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 09/25/2010 04:31 PM, Timothy Clark wrote:
<blockquote
cite="mid:AANLkTikmeGQSHKwmxCtHC_t0-fUZ6FdSen0FA4LbqVC+@mail.gmail.com"
type="cite">
<pre wrap="">is it free and will it work with my shoutcast server?
</pre>
</blockquote>
Yes, mpd is open source. See <a href="http://mpd.wikia.com/">http://mpd.wikia.com/</a>
It comes with the Ubuntu distribution (although I compiled ours from
source in order to configure it to stream in mp3 format).<br>
<br>
And yes, it can feed a shoutcast server. See <a
href="http://mpd.wikia.com/wiki/Configuration#IceCast">http://mpd.wikia.com/wiki/Configuration#IceCast</a><br>
<br>
-John<br>
<br>
<blockquote
cite="mid:AANLkTikmeGQSHKwmxCtHC_t0-fUZ6FdSen0FA4LbqVC+@mail.gmail.com"
type="cite">
<pre wrap="">
On 9/25/10, John List <a class="moz-txt-link-rfc2396E" href="mailto:johnlist@gulfbridge.net"><johnlist@gulfbridge.net></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">At WXBH-LP we had a similar need, and we solved it using mpd (music
player daemon) to coordinate our feed to icecast.
mpd is a music player (supporting playlists, etc.) originally designed
for local network streaming, but it has several attributes that make it
suitable for other things:
* Items in its playlists can be local audio files or remote streams
(e.g. DJ streams).
* It can output a stream directly to icecast.
* As a daemon it can be controlled by various clients including ones
accessible from the command line, the web, and telnet/ssh. This
has allowed us to build a scheduling system around it to cause it
to play particular playlists at their scheduled times.
Each remote DJ must generate his/her own stream to be picked up by mpd.
We make this easy by defining multiple "remote" streams for their use on
our icecast server. This has the advantage of letting them connect to
the remote stream early so they and we can verify that all is well. At
the scheduled time, that remote stream is then "played" from a playlist
on mpd.
We are a low-power FM station in the Louisville, Kentucky, area, and we
are run collectively, so having a distributed architecture (allowing
remote DJs) is important to us. Our mpd server, icecast server, and
transmitter are currently in three separate locations. A computer at the
the transmitter site subscribes to the icecast stream.
Unfortunately, it looks like we will be scrapping this system in a few
weeks in favor of a proprietary system (SAM Broadcaster) because it
offers superior sound level compression (i.e. it plays stuff louder)
which has a direct effect on the strength of our broadcast signal (which
is important when you are limited to 100 watts).
Until we switch away from mpd, you can learn more at our website,
<a class="moz-txt-link-freetext" href="http://wxbh.org/OurStationSoftware.html">http://wxbh.org/OurStationSoftware.html</a> and you can monitor the system's
operation from <a class="moz-txt-link-freetext" href="http://">http://</a> studio.wxbh.org/Console.html .
If anyone is interested in what we've done, I'll be happy to tell more
and share code.
-John Hicks
(For best results in communicating with me directly, substitute my name
"johnhicks" in place of "johnlist" in my email address.)
On 05/24/2010 12:10 PM, Patrick Bohnet wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I have been playing with Icecast only for a couple of days, and I am
trying to figure out how to do something.
I want a listener to have to only deal with one stream, but I want to be
able to switch the source of that stream between multiple sources (DJs).
The core idea is that the listener only deals with /live.mp3 while in the
background I can problematically switch between a series of live sources
(DJs) or an "Auto DJ Playlist" source - all based on a schedule for 24/7
content. The total amount of DJs is currently unknown (4+), as this is
just the planing stages.
So far I only have two ideas, neither of which seams optimal
1) use the move listener function to constantly shift users around to the
correct DJ stream.
2) use a third party restream program, such as StreamTranscoder or
LiquidSoap
3) use 4 dj mount points that fallback to each other and finally to the
autoDJ, and make the DJs pick a stream to take over when their show
starts. (this untested)
(Long discussion on how I don't know how to do that, and ways that I have
tried)
So far I have tried the following (this is on a Debian machine running
Icecast 2.3.2, all mounts are 128 kbs mp3, i can try a win32 version of
icecast2, but I assume there should be no functional difference)
*******************************************************************
This was my first setup to familiarize my self with icecast
mount /EDH.mp3 is hidden and not public - it has a source of Winamp and
edcast playing music from an old windows box I have
mount /live.mp3 has a fallback to /EDH.mp3 with a fallback override of 1
If the listener connects(windows media player on a windows box) to
/live.mp3.m3u they hear the autoDJ until i connect to /live.mp3 with SAM,
afterwhich they hear me, until I disconnect... so far so good
*******************************************************************
Next I tried the following, i wanted to try to swap the listener between
two live sources
mount /dj1.mp3 is playing music from Winamp/edcast on my old windows
machine (classical music)
mount /dj2.mp3 is playing music from Winamp/edcast on a second windows
machine (Ozzy Osborn)
mount /live.mp3 is setup with /dj1.mp3 as the fallback with fallback
override set to 1
When a listener connects (using windows media player on a third windows
machine), they hear dj1
I then, via the web interface
(<a class="moz-txt-link-freetext" href="http://www.icecast.org/docs/icecast-trunk/icecast2_admn.html">http://www.icecast.org/docs/icecast-trunk/icecast2_admn.html</a> i.e.
/admin/fallbacks?mount=/live.mp3&fallback=/dj2.mp3 ), change the fallback
of /live.mp3 to /dj2.mp3
the listener still hears dj1 and does not hear dj2.
if i disconnect the listener and re connect, I still heard dj1 and not dj2
even though when I use /admin/listmounts i see that /dj2.mp3 is listed as
the new fallback.
If i change the /etc/icecast2/icecast.xml to change the fallback there and
then run /etc/init.d/icecast2 reload to reload the config, the listener
still hears dj1, even on a listener reconnect.
I even try a /etc/init.d/icecast2 restart and it does not change. only
when I do a stop/start does any new connections to /live.mp3 switch to dj2
now, I am able to move listeners via the web interface from /live.mp3 to
/dj2.mp3 and they hear dj2. But if i try to move them back to /live.mp3
(thinking that it might then trigger the "new" fallback) they again hear
dj1
With some complicated checking, this might be a solution.
*******************************************************************
Next i tried using two icecast servers
Server A
I remove /live.mp3 from server A, otherwise it is the same server as
before
Server B (second Debian box, same subnet as all the machines, otherwise
identical configuration as Server A)
I add a relay called /live.mp3 which is using /dj1.mp3 from Server A as
the source
If a user connects to /live.mp3 they hear dj1
if i change the xml (since there does not seam to be a web interface for
editing relays) to point it to dj2 and do /etc/init.d/icecast2 reload
nothing changes. The listener still hears dj1, even on a listener
reconnect. If i do a stop/start only then does the listener hear the dj2,
but it forces a reconnect and interrupts the user.
*******************************************************************
Finally I tried using a third party program to act as the go between
Server A
(still has /dj1.mp3 and /dj2.mp3 with no change)
Server B
changed /live.mp3 from a relay to a mount with a fallback to /EDH.mp3
added /EDH.mp3 to this server and used a third windows box with Winamp and
edcast to stream)
on server B, I am running streamtranscoder from oddcast to stream /dj1.mp3
to /live.mp3
when a listener connects to server b /live.mp3 they hear dj1
when i stop the streamsstranscoder and run the one that points to /dj2.mp3
the user hears the autodj for just a second then they hear dj2
this solution does not actually need two icecast servers, i just had
things setup this way and did not want to move them around just for this
test
this solution is re encoding the mp3 stream, which is a loss of quality
*******************************************************************
it looks like my best option might be to have the DJs broadcast in 256kbs
mount points that are hidden, and use liquidsoap to rebroadcast it to the
live stream in 128kbs mp3. I can then control liquidsoap via an external
programmatic interface which allows me to switch from DJ to DJ based on a
timer, or to manually switch to a different show outside of the timer. I
just don't like that it will reencode the audio.
I was planning on using liquidsoap as the final auto dj (winamp/edcast was
just for testing) anyway
_______________________________________________
Icecast mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Icecast@xiph.org">Icecast@xiph.org</a>
<a class="moz-txt-link-freetext" href="http://lists.xiph.org/mailman/listinfo/icecast">http://lists.xiph.org/mailman/listinfo/icecast</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>