[Icecast] Typically end-to-end 'delay' of live audio

[Stéphane Benoit]

Hello,

Have you tried something like 
http://www.schillmania.com/projects/soundmanager2/ for your player ?

It looks promising.

Regards,
Stéphane Benoit.

Le 05/02/2015 17:30, Tony a écrit :
> 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 
> <mailto: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 <mailto:Icecast at xiph.org>
>     http://lists.xiph.org/mailman/listinfo/icecast
>
>
>
>
> -- 
> Tony
>
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20150206/03d5de42/attachment.htm>