Dropouts and disconnections on Icecast

[Michael Smith]

On Fri, Oct 28, 2011 at 10:20 PM, Jim Carter <jimc at math.ucla.edu> wrote:
> I'm trying to play audio from a CGI script executing on the playback
> host, keeping things as simple as possible, which turns out to be
> amazingly possible with GStreamer.  I'm execing this command line:
>    gst-launch playbin "uri=$MRL"
> This works excellently with local files and with streaming audio/mpeg
> (mp3) or audio/ogg.  However, I'm getting anomalies in two cases, both
> involving the output of a FM receiver compressed to either of these
> formats.  The rate of production of source content is controlled
> by the hardware (and source-side resampling parameters).


> My working hypothesis is that the source and sink clocks are not
> identical; case 1 happens if the sink is faster, while case 2 means the
> source is faster.

Your hypothesis is almost certainly correct.

Icecast doesn't control the speed at which a stream is sent - that's
up to the source, which as you say is controlled by some other
hardware.

GStreamer can control the speed at which a stream is consumed in a
number of ways - but essentially, it depends on the clock selected.

In an http-stream based playback scenario, the clock will usually be
an audio clock - and your audio playback hardware is not sychronised
to your source hardware's clock. So, as you've found, this eventually
leads to problems...

GStreamer can also use other clocks - in this particular case, you
want to re-synthesise a clock based on the average rate at which the
stream is being sent. GStreamer doesn't come with an element that
implements that, but you could write one. Other protocols that are
designed for real-time use (http, obviously, is not) may work better,
but icecast doesn't do that.

Mike