Re: [Savonet-users] question on sequential play
On Sat, Feb 5, 2011 at 6:20 AM, Hyun-ki Chung hyunkich...@yahoo.com wrote: BTW, the insert function loops on the last child, my promotion track - fail() doesn't seem to work, while your alternative that merges everything seems to work well in my case. That might be because I didn't understand how the inhibit parameter works in the cross function and didn't use it properly. Would you like to explain again what the role of inhibit is in the function? The sequence doesn't loop on the promotion tracks. What's happening is that after the promo track, there is an end of track before the first track of after. At this point cross() triggers another transition. That's where the inhibition parameter comes into play: it tells cross() not to trigger a transitions too close after another one, even if there is a new track. The alternative is to merge the promo track with the new normal track (the one from after in the transition) so that cross doesn't see an end-of-track. Hope this helps, -- David -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Savonet-users mailing list Savonet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/savonet-users
Re: [Savonet-users] active/standby configuration
Hi Peter, As you might suspect, it's hard to distinguish a short term failure from a real unavailability, and it certainly can't be done at the level of a fallback. Pretty much the only place to do this is when setting buffering parameters. I think you already know that and your goal is realistic: If net1 fails net2 gets active and master, if available. If net1 comes up again, net2 stays master and continues playing. If net2 fails net1 wll be come active and master, if available. What you want here is simply a track sensitive fallback between net1 and net2. As long as one of them is up and running, it should keep playing. If both fail, we go to fallback_net_outage. So you could simply set track_sensitive=true (the default) if I understand your needs correctly. I suspect you also want the outage source to stop playing as soon as a network comes back, in which case there is a track insensitive switch around a sensitive one: radio = fallback( track_sensitive=false, [ fallback([net1,net2]), fallback_net_outage ]) Cheers, -- David -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Savonet-users mailing list Savonet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/savonet-users
Re: [Savonet-users] double-utf8 metadata encoding with output.icecast and input.harbor
Thanks very much for your help rodger, I have fixed the problem. More details in http://dev.sourcefabric.org/browse/LS-473. If this seems all good to you as well I'll definitively close the issue. -- David -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Savonet-users mailing list Savonet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/savonet-users
Re: [Savonet-users] liquidsoap: ubuntu upstart script, log reader script
Hi David, Of course you can distribite the scripts, I would feel honored. As far as I understand upstart's exec method, it will fail as soon as the executed command returns. When I use liquidsoap's daemon mode upstart will respawn immediately after starting daemon and give up after 10 attempts in a short time. Maybe upstart offers an alternative mechanism to work with daemon processes, I just don't know. Thanks for answering to active/standby configuration thread, I have learned a lot from it, once again. BR, Peter Am 08.02.2011 08:42, schrieb David Baelde: Thanks Peter for sharing those. I assume we can distribute them? The upstart script is particularly interesting. However, I'm wondering why you didn't use the daemon mode (which would have merged stdout/stderr with the logs). See ya, -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Savonet-users mailing list Savonet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/savonet-users
Re: [Savonet-users] Default switch behaviour in liquidsoap
2011/2/7 kro...@aolohr.com:
Hi,
Hi Andre,
To better understand some strange behaviour with output from my
switch-based program scheduling, I'd like to clarify exactly what
is the default behaviour in liquidsoap.
I use 'track_sensitive=false' to trigger an abrupt end of the
current playing track when the 'Show block' allotted time expires.
icmp3 = mksafe(switch(
track_sensitive=false,
[
({09h00-09h30}, sstol),
({09h30-10h00}, mfts),
. . .
]
))
When the next switch element kicks in, it should play the first
item in the sequence that is defined for that new time-slot.
Now for the questions:
1. If a new listener tunes in part way through a time-slot, would
they hear only the current track in progress? Or would they hear
everything from the very beginning of the show's time-slot (even
though its 'play-time' has already occurred)?
2. If liquidsoap experiences a crash mid-way through a time-slot,
is restarted, would it restart the time-slot from its beginning?
3. Does the liquidsoap *remember* what has been played and cue
new listeners to that point?
About 1) and 3): the streams produced by liquidsoap have no
consideration for the listeners. They basically are continous flow of
audio data. Icecast does the work of redirecting this flow to each
listeners. Further, when a listener connects, he receives the stream
at the point it is in the view of icecast.
These aspects differ a lot with on-demand streaming systems when the
streams can be customized for each listener.
Concerning 2) when liquidsoap restarts, it will re-evaluate each
condition in the switch in the given order. The first one to return
true with an available source will be used to start the stream. For
instance, if it crashes at 9h45 and restarts at 9h50 and the mfts
source is available upon re-start then Liquidsoap will restart with
that source. Further, the source mfts will also be restarted. If it is
a sequence of requests, for instance, the sequence will restart from
its beginning.
However, we strongly believe that you should experience very few
liquidsoap crashes :)
Romain
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Savonet-users mailing list
Savonet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/savonet-users
