[Icecast] Typically end-to-end 'delay' of live audio
stefb at wizzz.net
Fri Feb 6 02:27:22 PST 2015
Have you tried something like
http://www.schillmania.com/projects/soundmanager2/ for your player ?
It looks promising.
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
> > 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.
> I'd probably be able to point out something more helpful, but you
> 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 /
> 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 <mailto:Icecast at xiph.org>
> Icecast mailing list
> Icecast at xiph.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Icecast