Ok, I'm happy to focus on other things for now, then. Thanks for sharing your expertise!
David On Wed, Oct 30, 2013 at 1: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 -- 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
