2011/5/13 Romain Beauxis <[email protected]>
> 2011/5/12 Marius Flage <[email protected]>:
> > Hi there!
>
> Hi Marius and welcome onboard!
>
Hi Romain, Hi Marius,
>
> > I'm the technical advisor for a local radio station. We broadcast on the
> > FM band and use regular FM transmitters to broadcast. Now we're looking
> > to expand to a different location, a location that's well hidden down in
> > a valley with steep mountains, so doing "FM hops" isn't exactly trivial.
> > So we thought about delivering the audio to the remote location over IP
> > instead and then output it to a FM transmitter at that location, with as
> > little latency as possible.
> >
> > So the question is if Liquidsoap is the way to go with this? I've been
> > looking at the Celt codec, but there's really no software readily
> > available that uses this codec. At least not that fits into our scenario.
> >
> > Of course stability and reliability are two other keywords for this. It
> > has to be robust enough to maintain a connection even if there's some
> > percentage of delay and/or packet loss (though this will be on fiber
> > connection, so it should be too much of a problem) and also reliability
> > meaning that it'll reconnect if it gets disconnected.
> >
> > Oh, and yeah, this has to run on headless servers running some variant
> > of Linux.
> >
> > Any ideas anyone?
>
> This is surely a possible application of liquidsoap. We have operators
> to pull data from an HTTP source (input.http) or receive it
> (input.harbor) and operators that can send data to another place
> (output.icecast) or act as an icecast mountpoint (output.harbor).
>
> All these operators use the TCP transport protocol, so reliability of
> the connection boils down to reliability of the TCP layer.
>
> You should also be able to run liquidsoap on most of the modern POSIX
> systems (BSD, Linux, OSX) so it most likely include your variant of
> linux.
>
> The only thing that you may keep in mind is that our internal audio
> representation is raw PCM (in fact float) streams. Therefore, if one
> of the incoming or outcoming data stream is encoder, liquidsoap will
> have to decode/encode. However, you may as well be able to use either
> WAV or FLAC format between two liquidsoap clients, although this
> requires some bandwidth.
>
> Finally, and because we should not be too exclusive, you may as well
> look at the relaying capabilities of icecast servers. If that is
> enough for you, then you would be able to setup a networks of icecast
> relays that do not need to encode/decode your data. The only
> difference in this case is that you would not be able to setup
> advances stream manipulation such as, for instance, a default fallback
> for when the distand stream is not available..
>
>
I am not advertising, and I'm pretty sure you can do that with liquidsoap,
but Marius - have you thought about proprietary / hardware audio over IP
solution ?
You can contact me directly if you would like to discuss more about it as I
am working on this kind of equipement @ work.
Cheers
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Savonet-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-users
