Icecast - Feb 2015 - Typically end-to-end 'delay' of live audio

I have an audio device driver for a live feed that produces Opus frames, if
I were to use icecast, what sort of real-time delay can I expect? 3-5s?
5-10s? more?

I've tried using the html5 <audio> tag directly to stream my source,
but it
seems browsers like to queue-up 250K to 500K of audio 'data' before they
begin playback.  That introduces a 15-30s delay depending on browser and
the audio compression used.  I'd like an html5 (plugin-less) solution that
introduces no more than a 3-5s delay.
-- 
Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20150205/1ad55029/attachment.htm>

On 02/05/2015 02:45 PM, Tony wrote:
> I have an audio device driver for a live feed that produces Opus
> frames, if I were to use icecast, what sort of real-time delay can I
> expect? 3-5s? 5-10s? more?
Likely that or more. This highly depends on the client side buffers.
Icecast itself doesn't buffer much and that can be disabled by turning
off the burst-on connect functionality.
HTTP streaming is not "real-time" for most values of real time,
it's
still more "real time" than HLS thought, to my surprise.

> I've tried using the html5 <audio> tag directly to stream my
source,
> but it seems browsers like to queue-up 250K to 500K of audio 'data'
> before they begin playback.  That introduces a 15-30s delay depending
> on browser and the audio compression used.  I'd like an html5
> (plugin-less) solution that introduces no more than a 3-5s delay.
Yes, you can't control client side buffers for HTTP based streaming to
browsers.

If you aim for something reliably <<5s without having total control of
the client side, then your best bet is to look at something else. Maybe
WebRTC?

I'd probably be able to point out something more helpful, but you don't
state your actual use case.

Generic standard comment:
Most cases where people think they need an Icecast stream to have a
"low" delay are cases where some slight change in approaching the
problem would help. E.g. for collaborative streaming a real time / VoIP
backend that then streams to Icecast. Or in case of a "internet radio"
a
question queue instead of trying to achieve "chat like response" over
the air, or rely on listeners actually "dialling in" through e.g. VoIP
for questions.


Cheers

Thomas

Thanks.  Here's bit more detail.

We have a scientific audio instrument that comes with its own audio
driver.  This driver gives us Opus 'frames'.  From a remote location
(typically less than 200mS round trip) we would like someone using a
browser (without a plugin) to 'hear' this device.  We need the low
end-to-end delay as there is an active Video session (separate application)
connecting the same two locations.  The remote participant has the ability
to mute either feed (video or scientific device).  However, if the device's
feed is too far 'delayed' from the video feed, it becomes rather
annoying
for the remote participant even with the audio portion of the video feed
muted.

Today, we have a browser plugin.  And we transmit the device's audio data
to the remote participant via websockets, wherein the browser feeds the
data to the plugin for decoding and playback.

Unfortunately, browser plugin's are dying technology.  In fact, chrome is
phasing them out later this year.  And Firefox claims they will do the same
"soon".  So, we need to find a replacement.


On Thu, Feb 5, 2015 at 11:03 AM, "Thomas B. R?cker" <thomas at
ruecker.fi>
wrote:
> On 02/05/2015 02:45 PM, Tony wrote:
> > I have an audio device driver for a live feed that produces Opus
> > frames, if I were to use icecast, what sort of real-time delay can I
> > expect? 3-5s? 5-10s? more?
>
> Likely that or more. This highly depends on the client side buffers.
> Icecast itself doesn't buffer much and that can be disabled by turning
> off the burst-on connect functionality.
> HTTP streaming is not "real-time" for most values of real time,
it's
> still more "real time" than HLS thought, to my surprise.
>
>
> > I've tried using the html5 <audio> tag directly to stream my
source,
> > but it seems browsers like to queue-up 250K to 500K of audio
'data'
> > before they begin playback.  That introduces a 15-30s delay depending
> > on browser and the audio compression used.  I'd like an html5
> > (plugin-less) solution that introduces no more than a 3-5s delay.
>
> Yes, you can't control client side buffers for HTTP based streaming to
> browsers.
>
> If you aim for something reliably <<5s without having total control
of
> the client side, then your best bet is to look at something else. Maybe
> WebRTC?
>
> I'd probably be able to point out something more helpful, but you
don't
> state your actual use case.
>
> Generic standard comment:
> Most cases where people think they need an Icecast stream to have a
> "low" delay are cases where some slight change in approaching the
> problem would help. E.g. for collaborative streaming a real time / VoIP
> backend that then streams to Icecast. Or in case of a "internet
radio" a
> question queue instead of trying to achieve "chat like response"
over
> the air, or rely on listeners actually "dialling in" through e.g.
VoIP
> for questions.
>
>
> Cheers
>
> Thomas
>
>
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>


-- 
Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/icecast/attachments/20150205/162c388f/attachment.htm

This is slightly off topic, but why fuss over broadcast delay budget?
What are you broadcasting that's so sensitive to delay?

Curiously,
Daniel

Tony <yellowjacketlite at gmail.com> writes:
> I have an audio device driver for a live feed that produces Opus frames, if
I were to use icecast, what sort of
> real-time delay can I expect? 3-5s? 5-10s? more?
>
> I've tried using the html5 <audio> tag directly to stream my
source, but it seems browsers like to queue-up 250K to
> 500K of audio 'data' before they begin playback.? That introduces a
15-30s delay depending on browser and the audio
> compression used.? I'd like an html5 (plugin-less) solution that
introduces no more than a 3-5s delay.
> --
> Tony
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast