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

[Michel Memeteau]

Just my thoughts : Flash is dead and even be blocked as a default in a
near future by most browsers.

I don't think the delay is on the browser side, but more on the
processing/server side here.
<----------------------------------------------------------------------------------------------------------->
http://shop.ekimia.fr : Achetez votre PC Ubuntu Linux en ligne , support inclus.
Photos perso sur : http://memeteau.org


2015-02-06 13:41 GMT+01:00 Tony <yellowjacketlite at gmail.com>:
> 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 list
>> Icecast at xiph.org
>> http://lists.xiph.org/mailman/listinfo/icecast
>>
>>
>>
>> _______________________________________________
>> Icecast mailing list
>> 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
>