Hi Shaun,

What you're describing is a nice way to combine two sources into one
while encoding only the combined source, by using harbor with raw data
between sources. However, the issue discussed here is about having a
single source stream to two different icecast; for this problem I
don't see a similar solution.

Cheers,

David

On Thu, Oct 31, 2013 at 11:22 AM, Shaun Dewberry
<shaun.dewbe...@gmail.com> wrote:
> Hi
>
> I might be waaay off - haven't worked on my liquidsoap stuff in quite some
> time, but I was thinking something along the lines of this:
>
> server1_source audio -> server1_output.harbor -> edgeserver_input.harbor
> with check for failover to alternate stream -> edgeserver_icecast/shoutcast
> edge server
> server2_source audio -> server2_output.harbor -> edgeserver_input.harbor2
>
> Or perhaps output.gstreamer/input.gstreamer.
>
>
> Shaun.
>
>
>
>
>
> On Thu, Oct 31, 2013 at 12:05 PM, David Baelde <david.bae...@gmail.com>
> wrote:
>>
>> Hi Shaun,
>>
>> I'm not sure I understand your suggestion. Liquidsoap can send raw PCM
>> data to harbor, or jack but not to icecast as far as I know. What do
>> you have in mind?
>>
>> David
>>
>> On Thu, Oct 31, 2013 at 9:02 AM, Shaun Dewberry
>> <shaun.dewbe...@gmail.com> wrote:
>> > Hi,
>> >
>> > For scenario B:
>> > What about having a simple non-encoding liquidsoap script running on
>> > your
>> > endpoint servers feeding the local icecast/shoutcast and have it collect
>> > the
>> > stream from multiple sources and build in the logic to switch between
>> > those
>> > sources if there is a problem with one?
>> >
>> > Just a thought...
>> >
>> > Shaun.
>> >
>> >
>> > On Wed, Oct 30, 2013 at 2:57 PM, Matt Camp <m...@noise.net.nz> wrote:
>> >>
>> >> On 30 Oct 2013, at 09:42, David Baelde <david.bae...@gmail.com> wrote:
>> >>
>> >> > Hi Matt,
>> >> >
>> >> > A long time ago, Liquidsoap could do what you're looking for. We
>> >> > dropped it when moving to a better design, making things more uniform
>> >> > by treating outputs like other operators. So it's possible (and not
>> >> > very hard technically) to do this, but it requires some thinking and
>> >> > a
>> >> > fair amount of coding. I'm not sure we have the time for that right
>> >> > now... I guess it depends on the pressure/help from the community.
>> >> >
>> >>
>> >> Thanks, that has answered my question... I just wasn't sure if it was
>> >> something that liquidsoap could already do to improve efficiency.
>> >>
>> >> I don't really think there is a lot of point investing too much energy
>> >> in
>> >> adding this feature, at least not specifically for supporting low-power
>> >> encoder systems...
>> >>
>> >> I've now tested liquidsoap on a variety of embedded arm platforms, and
>> >> while the raspberry pi gets the most media attention, it's also by far
>> >> the
>> >> most inferior. It's probably still the cheapest, but when you consider
>> >> you
>> >> can get double the CPU power for around £5 more it doesn't really make
>> >> sense
>> >> as an audio encoder.
>> >>
>> >> These embedded systems are evolving so rapidly (8-core 2ghz available
>> >> is
>> >> few months) that I doubt CPU power will really be a problem for long
>> >> anywhere other than the extreme budget end of the scale.
>> >>
>> >> As for my use cases the main two are:
>> >>
>> >> A: streaming to both icecast and shoutcast simultaneously (yes,
>> >> shoutcast
>> >> can relay an icecast stream, but it's messy when dealing with lots of
>> >> streams and it also usually means the relayed stream can't be listed in
>> >> the
>> >> shoutcast yp directory)
>> >>
>> >> B: streaming to two separate icecast servers. I run a network of
>> >> servers
>> >> with multiple front-end servers relaying off a pair (actually more) of
>> >> back-end icecast servers which the sources connect to. This all works,
>> >> but
>> >> there are cases such as Internet routing issues or server failure where
>> >> the
>> >> source encoder can no longer reach the first source icecast server. DNS
>> >> records with multiple IPs sort of works with some encoders, but there
>> >> is
>> >> still usually a period where the whole stream is missing before the
>> >> source
>> >> encoder connects to the other source server... If there was a source
>> >> stream
>> >> going to both source servers then failover would be a lot faster, and
>> >> likely
>> >> not even drop the stream for the listeners.
>> >>
>> >> In both cases I want to send an identical stream to more than one
>> >> server.... But it's still totally doable now with liquidsoap.... I was
>> >> just
>> >> wondering if there was a more efficient way to do it.
>> >>
>> >> Cheers.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Android is increasing in popularity, but the open development platform
>> >> that
>> >> developers love is also attractive to malware creators. Download this
>> >> white
>> >> paper to learn more about secure code signing practices that can help
>> >> keep
>> >> Android apps secure.
>> >>
>> >>
>> >> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>> >> _______________________________________________
>> >> Savonet-users mailing list
>> >> Savonet-users@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/savonet-users
>> >
>> >
>> >
>> >
>> > --
>> > http://www.dewberry.co.za
>> > .gsm +27 83 415 5201
>> >
>> > Don't ignore your dreams; don't work too much; say what you think;
>> > cultivate
>> > friendships; be happy.
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Android is increasing in popularity, but the open development platform
>> > that
>> > developers love is also attractive to malware creators. Download this
>> > white
>> > paper to learn more about secure code signing practices that can help
>> > keep
>> > Android apps secure.
>> >
>> > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > Savonet-users mailing list
>> > Savonet-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/savonet-users
>> >
>>
>>
>>
>> --
>> David
>>
>>
>> ------------------------------------------------------------------------------
>> Android is increasing in popularity, but the open development platform
>> that
>> developers love is also attractive to malware creators. Download this
>> white
>> paper to learn more about secure code signing practices that can help keep
>> Android apps secure.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Savonet-users mailing list
>> Savonet-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/savonet-users
>
>
>
>
> --
> http://www.dewberry.co.za
> .gsm +27 83 415 5201
>
> Don't ignore your dreams; don't work too much; say what you think; cultivate
> friendships; be happy.
>
> ------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> _______________________________________________
> Savonet-users mailing list
> Savonet-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/savonet-users
>



-- 
David

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Savonet-users mailing list
Savonet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/savonet-users

Reply via email to