Hi,

Welcome to liquidsoap :) Romain will be glad to hear that his article
in GLMF has been effective.

On Mon, Mar 17, 2008 at 10:38 PM, Benoït Leudet <[EMAIL PROTECTED]> wrote:
>  First, the delay:
>  I need to put a delay for live sessions (30 to 90 seconds) because we
>  shoutcast some games and we want to reduce the delay with games TV
>  servers for the listeners.
>
>  But the delay doesn't work. When I run my .liq with a delay of 30s, the
>  first time live source is connected, the delay is only 5 seconds and the
>  following are 15 to 25 seconds. The problem is that is never the same time.
>  Bug in the delay or is the method bad?

Here my answer will be very simple. You have misunderstodd the delay()
operator. Double-check the documentation (liquidsoap -h delay): this
operator prevents a source to play two tracks with less than a certain
delay between the two. It has nothing to do with the delay/latency
associated with an input. This latency problem is only relevant to the
input itself.

I'll insist by pointing at some design properties of liquidsoap, that
are good to have in mind sometimes. In liquidsoap, operators have only
a very local view of the situation: they see their immediate children,
and their parents. Plus, they are generic in that they can take any
source, built out of any functions. It is impossible to expect that an
operator can lower the latency of any input, because the operator
doesn't even know that the source is an input, and even if it knew
that, it doesn't know anything about how the input inputs data.

More to the point: you're asking how to get a better latency. First,
remove that delay(), because it will make fast reconnections (which
cause a new track) useless, by enforcing 30 seconds of not being ready
-- in other words, hiding for 30s the fact that the source has some
data, i.e. that the client reconnected.

Then if you need a really low latency, try using jack... or at worse
the very experimental RTP.

>  The second thing is switch:
>  I would like to do this: when playlists are changed with switch (with
>  track_sensitive=false), I would like to skip the song of the previous
>  playlist. I tried this
>
>  def start(a, b)
>     source.skip(a)
>     sequence([jingle, b])
>  end

This seems good to me. Actually it's pretty close to what is done in
fallback.skip() in our utils.liq. But that's not what I see in your
script: in live2playlist you skip on b, i.e. you kill the next track,
not the (end of) the previous one.

>  # changement toutes les 30s pour tester
>  playlists = switch(track_sensitive=false,
>                     [({0s-29s}, start(reggae, electro)),
>                     ({30s-59s}, start(electro, reggae))])

Your start() function was good... for a transition. You should use it
as follows:
   playlists = switch(track_sensitive=false, transitions=[start,start],
                      [({0s-29s}, electro),
                      ({30s-59s}, reggae)])

The idea is that the transition function must be passed, so that it
can be later used between each two tracks -- you don't know in advance
what will be those tracks. In what you wrote the function was
evaluated only once, for creating a source that was passed to
switch(). I know this is difficult to figure out, in case you're not a
programmer.

>  # un jingle comme intro, puis la playlist
>  def start(a)
>     sequence([jingle, a])
>  end
>  playlists = switch(track_sensitive=false,
>                     [({0s-29s}, start(electro)),
>                     ({30s-59s}, start(reggae))])

You have the same problem here. Only one sequence is ever built, so
only one jingle will be ever played. If you want one introductory
jingle any time you switch back to a playlist, use a transition:
  def start(a,b)
    sequence([jingle,b])
  end
  playlists = switch(track_sensitive=false, transitions=[start,start],
                      [({0s-29s}, electro,
                      ({30s-59s}, reggae])

>  radio = normalize(radio)
>  radio = compress(radio)

I have already said too much in that mail, so I'll only be very short
about that one: you'll find out that normalize() sometimes saturates.
(Hint: Sam, fix it!) Eventually, you might want to ask me how to use
replaygain with liquidsoap, I've found that it is a much better
solution when possible.

Have fun, and good luck.
-- 
David

Reply via email to