[Icecast] Using Icecast relay function with dynamic IP at remote source end
Jack Elliott
thatjackelliott at kpov.org
Wed Apr 19 23:00:23 UTC 2017
Hi David, I don't think we will necessarily be on wifi, I'm sorry if I
implied that. There are a couple of events each year when we have to use
wifi, but for those I have a dedicated access point running at close to
1 watt connected directly to our ISP's network.
Okay, I was told over on the Darkice listserv that using Darkice > WAN >
Icecast is not very reliable, and my testing supported that statement.
They said that Darkice is an encoder, and Icecast is a transporter.
Icecast, they said, is very reliable, Darkice is a good encoder but not
too great as a transporter.
I've been using BUTT as the encoder at the remote (audio source) end,
and sending the stream over the WAN to the Icecast server at the station
building. BUTT, I found, is more reliable than Darkice at the encoding end.
Here's how I've been doing it:
BUTT --> localhost Icecast server ===> WAN ===> Icecast server
I thought I might try this instead:
BUTT ===> WAN ===> Icecast server
Now here I want to avoid using incorrect terminology. The way I am using
the word "remote" is how it is used in broadcast: if a crew leaves the
building to broadcast an event occurring outside the station somewhere,
they are doing a remote.
So in my case, the "remote" is at the music festival - my audio source.
So when you write, "The relay easiest to configured in a pull
configuration. Where the setting are setup on the remote server." -- is
it correct for me to interpret that to mean that I can leave the
settings on the station computer's server alone, just set up the server
in my remote kit to "pull" from the station's server?
I am puzzled by "pull," since I am wanting to send audio from me to the
station, but that's pulling?
--
That Jack Elliott
(541) 848 7021
KPOV 88.9 FM High Desert Community radio
Producer, The Wednesday Point
Host, The Sunday Classics
On 4/19/2017 10:26 AM, David Saunders wrote:
> Hey,
>
> The relay easiest to configured in a pull configuration. Where the
> setting are setup on the remote server.
>
> Since the client is on WiFi, you will have lots of issues streaming
> due to the ever changing wifi environment. My suggestion is source the
> stream at the lowest settings for encoding you can live with, This
> will keep the bandwidth down and less likely burp on you.
>
> We do have clients who use WiFi and set the the encoding to smallest
> size for the content being recorded. Most of the time since its voice
> content we really don't have to go super high on the encoding.
>
> I have set up the relay to supplement our bandwidth when we think it
> will be over the limit. Just remember you need to give the listeners
> the remote server connection info not the local server.
>
> Why it would be better? not sure why, but if the icecast server is
> set with a larger buffer, it will buffer thru the disconnects of the
> source.
>
> David.
>
> On Wed, Apr 19, 2017 at 11:02 AM, Marvin Scholz <epirat07 at gmail.com
> <mailto:epirat07 at gmail.com>> wrote:
>
>
>
> On 19 Apr 2017, at 16:20, Jack Elliott wrote:
>
> For our community radio station's live music festivals
> broadcasts, we set up a small broadcast studio at the
> festival's venue, and use B.U.T.T. to send a stream to an
> Icecast server located at the radio station's building.
>
> REMOTE LOCATION STATION BUILDING
> B.U.T.T. ======= WAN =======>> ICECAST SERVER
>
> It's pretty reliable, though BUTT does sometimes lose
> connection, probably due to network congestion.
>
> The folks on the Darkice listserv claim that using Icecast to
> do the sending provides a more reliable connection. So I want
> to try this idea:
>
> REMOTE LOCATION STATION
> BUILDING
> B.U.T.T. --> Icecast on localhost ==== WAN ====>> ICECAST SERVER
>
>
> I am not sure how this could be more reliable than BUTT alone.
>
>
> I'm finding the terminology for setting up a relay (on
> http://icecast.org/docs/icecast-2.4.0/config-file.html#relay
> <http://icecast.org/docs/icecast-2.4.0/config-file.html#relay>)
> to be a bit confusing and could use some help.
>
> I believe I want to set up a Specific Mountpoint Relay. It's
> where the IP addresses get plugged in that I need some
> clarification. The IP address for the building is static, but
> the IP address for the remote server is unknown before every
> festival, and may be dynamic.
>
> The documentation says that for the <relay> section of the
> xml, we have a <server>127.0.0.1</server> setting. And that is
> described as "This is the IP for the server which contains the
> mountpoint to be relayed."
>
> I can't tell whether the <relay? section is on the remote
> server, in which case we only need to put the static IP of the
> building in the <server> section, or whether the <relay>
> section is on the building's server, in which case we need to
> know ahead of time what our remote IP will be, and hope it
> doesn't change during the festival.
>
> I hope this question makes sense. My confusion is clearly
> because I am unclear which server (remote or building) the
> <relay> section applies to.
>
> --
> That Jack Elliott
> (541) 848 7021 <tel:%28541%29%20848%207021>
> KPOV 88.9 FM High Desert Community radio
> Producer, The Wednesday Point
> Host, The Sunday Classics
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org <mailto:Icecast at xiph.org>
> http://lists.xiph.org/mailman/listinfo/icecast
> <http://lists.xiph.org/mailman/listinfo/icecast>
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org <mailto:Icecast at xiph.org>
> http://lists.xiph.org/mailman/listinfo/icecast
> <http://lists.xiph.org/mailman/listinfo/icecast>
>
>
>
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20170419/cd435f18/attachment.htm>
More information about the Icecast
mailing list