Hi Andy, I'm glad liquidsoap worked for you. Here are a few answers to help you out in your cleanup process. It's probably a good idea to start new threads for individual questions that you want to discuss in more details.
On Fri, Jun 15, 2012 at 2:18 AM, Andy Durant <[email protected]> wrote: > Things we want to achieve: > - Actually implement the commented out playlists: > Currently we use delay to go between the A list (about 20 tracks) > and the Normal List (about 150 tracks). > I guess just using random(weights=[], []) is best? Yes, random() or rotate() are usually preferable to delay(). > - Re-factoring out parts of the code into separate files to allow > individual restarts: > Is this actually possible? > I saw an init script that should allow this, but would having > playlists defined separately be useful? > Does anyone use a very modular system? How do you do it? It is possible to have several liquidsoap instances, with different scripts, interacting through HTTP, Jack, etc. I/O. It is not possible to restart part of a script, even if it's a separate file that is included in the main script file. > - Implementing 'Campus_Playout': > We made a system to take in the http stream from the live output so > that the 'campus_playout' output could be switched manually to live rather > than jukebox, but wasn't ideal. The best way seems to be harbors, is there a > way to set a flag to switch this on and off automatically? Harbor would give you more control on buffers and authentication, this may be welcome. Using custom authentication, you could make it impossible for external streams to connect at all during some periods. It is also possible to kick sources, and there has been discussions about this on the list. Finally, you could also allow streams to be connected to your harbor input but not play the harbor input. Note that it is also possible to dynamically create and destroy harbor inputs, but this is quite advanced and probably not necessary. > - Sorting out the clocks: > On each output there is a separate clock, this was to try and combat > an issue where all outputs sped up if we tried to use smart_crossfade on the > 'campus_playout' stream. Is what we've done wrong, or badly implemented, as > it didn't seem to solve the issue, but does provide multiple threads for > liquidsoap to run in. > The mksafe(buffer(jukebox)) on each output seems unnecessary, but > liquidsoap seems to complain if it's not there, why is this? and how can we > fix it? You should not use crossfade on an HTTP input, as you do on line 90 of your script. Use crossfade operators only on playlists, and switch (or fallback) transitions for smoothing the switching between playlists and live streams. Apart from this, using clocks on each output can be a good idea but for totally different reasons, namely avoiding that the lag on one output interferes with others. In that case the mksafe(buffer(X)) is a normal thing to do, although mksafe() may be problematic with encoded outputs as documented in the FAQ. > - OB-line input: > Currently for outside broadcasts the audio is streamed from a laptop > to icecast, then re-streamed internally to live. We'd quite like to automate > this, and also to reduce the extra delay this creates. A simple way would > seem to be streaming directly to the server and using a harbor. What are > your thoughts on implementing this? > One thing we have been looking into is using netJACK to connect from > OB to studio. would this be as simple as taking input.jack or should more be > done? Harbor would give more control on buffers, and more reactivity in general, it's the first thing to try. I can't promise much about our jack input, and even less about netjack. Only that if it works, it'll have a lower latency than more common solutions. Another possibility is to do MP3 over UDP using input/output.udp(): it's a straightforward hack but it works surprisingly well as far as I can tell. All the best, -- David ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
