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

[Tony]

Not yet.  We have thought about going to flash in hopes it would provide
less latency, but I haven't looked into it yet.  Though, technically, flash
is a plugin, but it seems to have earned "special status" by the browser
developers.

On Fri, Feb 6, 2015 at 5:27 AM, Stéphane Benoit <stefb at wizzz.net> wrote:

>  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>
> 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
>
>
> _______________________________________________
> Icecast mailing listIcecast at xiph.orghttp://lists.xiph.org/mailman/listinfo/icecast
>
>
>
> _______________________________________________
> 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/20150206/8ef25521/attachment.htm>