Dropouts and disconnections on Icecast

[Jim Carter]

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).

I can send the FM stream either as the HTTP response of my webserver
(with HTTP headers and a captured and re-played Vorbis header prepended),
or through an Icecast server which takes care of both those items
professionally.

The first anomaly is seen from both the plain webserver and Icecast.
Occasionally, like once every 1 to 2 hours, playback will fall silent
for about a second, then the audio will continue exactly where it left
off, i.e. I can't hear any missing segment.

The second anomaly is seen only from Icecast: the server logs
"INFO source/send_to_listener Client 346 (192.9.200.208) has fallen too
far behind, removing", whereupon the playbin's input is chopped.  This
happens maybe twice a day, on days that it happens.

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.

Following suggestions and examples in the GStreamer documentation,
I tried: gst-launch-0.10 uridecodebin "uri=$MRL" ! audioconvert ! \
  audioresample ! autoaudiosink
With an Icecast source while I was watching standard error it produced
one dropout (type 1) and said this:

Setting pipeline to PAUSED ... #At startup
Pipeline is PREROLLING ...
Prerolled, waiting for buffering to finish...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstPulseSinkClock
Buffering, setting pipeline to PAUSED ...
Prerolled, waiting for buffering to finish...
Done buffering, setting pipeline to PLAYING ... #Now it plays
Buffering, setting pipeline to PAUSED ... #Audio pauses
Prerolled, waiting for buffering to finish...
Done buffering, setting pipeline to PLAYING ... #Audio resumes

I thought that audioresample would match the source and sink clocks.
Does anyone have a suggestion how to resample so as to work around
differing (and possibly slightly variable) source and sink clocks?

Context is gstreamer-0_10-0.10.34 from Packman on OpenSuSE v11.4 Linux.
Audio sink is 0d8c:0103 C-Media Electronics, Inc. CM102-A+/102S+ Audio
Controller via pulseaudio-0.9.22.  Audio source is 06e1:a155 ADS
Technologies, Inc. FM Radio Receiver/Instant FM Music (RDX-155-EF)
via alsa-1.0.24.1 (not pulseaudio).


James F. Carter          Voice 310 825 2897    FAX [phone]
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: [hidden email]  http://www.math.ucla.edu/~jimc (q.v. for PGP key)
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne]

Le vendredi 28 octobre 2011 à 22:20 -0700, Jim Carter a écrit :

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"

I would suggest using playbin2 element instead, I don't pretend this is the issue, but it may help.

Nicolas


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[michael smith-6-3]

On Fri, Oct 28, 2011 at 10:20 PM, Jim Carter <[hidden email]> 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
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Jim Carter]

On Sat, 29 Oct 2011, Nicolas Dufresne wrote:
> Le vendredi 28 octobre 2011 à 22:20 -0700, Jim Carter a écrit :
>> (snip) I'm execing this command line:
>>      gst-launch playbin "uri=$MRL"
>
> I would suggest using playbin2 element instead, I don't pretend this is
> the issue, but it may help.

Thanks for the pointer, and it's worthwhile switching to the new playbin in
any case.  It works nicely but doesn't magically fix the clock speed issue.

On Sat, 29 Oct 2011 13:16:38 -0700, Michael Smith <[hidden email]> wrote:
> ... you could write one ...

You mean I have to actually do some work??? :-)  I think you're right, that
I need to come up with a clocksource different from both the not truly
isochronous source and the inexact sink.

A year or two ago on the PulseAudio list, someone was playing the same
stream on 2 or 3 playback nodes in different rooms (for a party), and when
the beer was all gone they were several seconds out of sync.  I don't
remember if he ever got a resolution; I think not.

What led me to sniff around the resample element was, when unusual CPU load
on the source impairs timely sending of the stream, the playback node will
fall silent briefly, then play "fast forward" to get back on schedule.  So
I thought the resampler was looking at the buffer fullness, but I guess I
was wrong.

James F. Carter          Voice 310 825 2897    FAX [phone]
UCLA-Mathnet;  6115 MSA; 520 Portola Plaza; Los Angeles, CA, USA  90095-1555
Email: [hidden email]    http://www.math.ucla.edu/~jimc (q.v. for PGP key)
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel