[Icecast] Typically end-to-end 'delay' of live audio
yellowjacketlite at gmail.com
Fri Feb 6 04:41:56 PST 2015
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
On Fri, Feb 6, 2015 at 5:27 AM, Stéphane Benoit <stefb at wizzz.net> wrote:
> Have you tried something like
> http://www.schillmania.com/projects/soundmanager2/ for your player ?
> It looks promising.
> 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
> 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>
>> 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
>> 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
>> 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.
>> Icecast mailing list
>> Icecast at xiph.org
> Icecast mailing listIcecast at xiph.orghttp://lists.xiph.org/mailman/listinfo/icecast
> Icecast mailing list
> Icecast at xiph.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Icecast