Hello,
On 18 Jul 2011, at 15:54, okay_awright wrote:
> hey
>
> On 17/07/2011 09:05, Jean-Francois Mauguit wrote:
>> Here, we are running 5000 radios using liquidsoap :-) We are using
>> request.dynamic which is calling a service 10 seconds before the end of the
>> current track to know what it has to play next. Our radio planning tool is
>> storing in a db all the planning of the radios and the service has just to
>> get what should be played and returns it to Liquidsoap. So it deliver the
>> right sound at the right moment. RadioDJ could change their planning when
>> they want, it updates the DB and the next LS call will return the new sound
>> to play.
>>
>
> Just out of plain curiosity: how high is the charge on your systems with
> that many radio stations? how many liquidsoap instances are running? on
> how many machines?
>
We are using SuperMicro Twin (two mother board dual socket in 1 U). Each server
is using dual xeon and is able to manage 160 simultaneous LS instance (and all
the framework built around LS). So we are providing 320 liquidsoap instance per
1 U.
> The 10s time limit sounds nice but I don't think I can rely on this,
It's the default behavior of the 0.9.3. We don't use the conservative parameter.
> tracks can be located on temporarily congested networks, and depending
> on user-defined file processing on Liquidsoap's end (e.g. compression) I
You could also ask liquidisoap working with 1 track in the queue in this case.
> wouldn't assume buffering times and latencies are always identical. It's
> after all LS's own duty to manage its queue according to its own
> timings, and it performs that job wonderfully BTW.
> Did you ever encountered inconsistencies within your queue with such a
> short time for injection? Are you files located on a network? what's
No LS plays exactly what he has to play when he has to play :-) Our files are
stored on a 30 TB supermicro server (16 HDD of 3 TB in RAID6 + spare -mirrored
on a second server in case of failure).
> your effective bandwidth and protocol for fetching files?
The bandwidth is 1 Gbps between the LS servers and the storage.
> I wanted that kind of features to take care of situations where no
> playlist should be played (radio intentionally off air), I think I can
> simulate that by forcing Liquidsoap to output silence for the given
> period (using 'blank'). When Liquidsoap is requesting the next track to
> play, I'll check the retrieved metadata and either switch to a plain
> request.dynamic(request.create()) if the radio has actually something to
> play, or blank otherwise. Maybe you can think of something better? Let
> me know.
Here radios are never off air :-) If the radio is live, it plays the stream
from the DJ computer and when it's not live, it's playing from the planning the
DJ has sent to us. The request.dynamic is the fallback of the input.harbor.
It's working fine :-)
Moreover, when the live stream is updating the metadata, the on_metadata allows
us to catch what is played (important for copyright payment).
If I had to play blank during a time, I think I'll use a specific mp3 (let's
say about 60 seconds) just containing blank. If I need to switch back to the
sound at a specific time, I'll cut the last one (using same mp3splt system) to
end at the exact time. Next it will play the sound back at the right time.
We are able to use top of the hour here. We are able to cut the sound playing
over the top of the hour to play it at the right time. We are able but we don't
do it always. In fact our service called by dynamic.request could take some
decision :
- if the current song ends between h:59 and h:01, the ToH will be played next
- if the current song ends after h:01, it will be cut at h:00 and the ToH will
be played at this time
- if the current song ends before h:59, we'll play a new sound and check when
it'll finish and apply the same rules as above
It sounds this 1 minute difference for the ToH is acceptable in regular radios
so we did the same. But we could always cut the sound to play the ToH at the
right time.
> Perhaps I can do something with at() as well, but its usage sounds
> obscure and I still don't know if it really interferes with the queue
> scheduling - BTW I guess the specified time is system-dependant, i.e.
> based on the server time zone, and cannot go lower than the minute in
> precision.
The precision is of course related by the clock of our services server (and not
the LS one). In fact we could reach a couple of second in precision on the LS
itself. But as there are a lot of buffers between LS and the listeners, on the
client side it's not the same :-)
We know when LS is starting the sound at 1 second precision, we know the
duration of the sound and exactly when it will mix the next sound in the
current song. So we know exactly when the next sound will start (our timestamp
in DB are using a ms precision).
>
>>> -can play a track for a specified duration only. Like before, this
>>> duration cannot be part of the configuration file.
>>> And, finally, if a webservice of some sort (REST, SOAP, whatever) is
>>> planned in replacement or to complete the Telnet interface.
>>
>> Our service called by liquidsoap is able to decide the duration of the track
>> to play (if it has to shorten the tracks due to an top of the hour, news,
>> meteo, or something else it could do it). In fact we are using mp3split in
>> front of liquidsoap to cut the mp3 (get the entry point and the exit point).
>
> It sounds reasonable.
> Do you really cut the mp3 beforehand, or do you just add cue points and
> use the new cue_cut operator?
We are really cutting the sound using mp3splt. We are doing that each time we
are playing the sound as the dj could change all the pointers between 2
diffusions. I didn't use cue_cut operator. I think it's in 1.0 version, isn't
it ? We are still using 0.9.2 and 0.9.3. Moreover we have to test first what is
lighter between mp3splt and cue_cut as we have to put a lot of LS instances on
the same server.
> I you don't really cut tracks, I guess I can just add the related
> metadata myself, on-the-fly, without relying on mp3split or MP4, FLAC
> and OGG equivalents.
I'll have to check version 1.0 as it sounds to be more stable now. Our concern
is just about stability (we have liquidsoap instances running for months
without any trouble) and scalability. We are not using the ID3 for the
metadata, the service is providing the right information to LS (using annotate).
>
> Thanks for your input Jean-François.
>
Hope Shampoo will come soon ;-)
Best regards,
Jef
>
------------------------------------------------------------------------------
Storage Efficiency Calculator
This modeling tool is based on patent-pending intellectual property that
has been used successfully in hundreds of IBM storage optimization engage-
ments, worldwide. Store less, Store more with what you own, Move data to
the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/
_______________________________________________
Savonet-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-users
