[Icecast] Using Icecast relay function with dynamic IP at remote source end
Jack Elliott
thatjackelliott at kpov.org
Wed Apr 19 23:33:19 UTC 2017
/I made an error, I swapped two diagrams, it should be this:/
Here's how I've been doing it:
BUTT ===> WAN ===> Icecast server
I thought I might try this instead:
BUTT --> localhost Icecast server ===> WAN ===> Icecast server
--
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 4:00 PM, Jack Elliott wrote:
>
> 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
>
>
>
> _______________________________________________
> 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/c50a63d1/attachment.htm>
More information about the Icecast
mailing list