<div dir="ltr">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.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 6, 2015 at 5:27 AM, Stéphane Benoit <span dir="ltr"><<a href="mailto:stefb@wizzz.net" target="_blank">stefb@wizzz.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<br>
Have you tried something like
<a href="http://www.schillmania.com/projects/soundmanager2/" target="_blank">http://www.schillmania.com/projects/soundmanager2/</a> for your player ?<br>
<br>
It looks promising.<br>
<br>
Regards,<br>
Stéphane Benoit.<br>
<br>
<div>Le 05/02/2015 17:30, Tony a écrit :<br>
</div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">
<div>
<div>Thanks. Here's bit more detail.<br>
<br>
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.<br>
<br>
</div>
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.<br>
<br>
</div>
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.<br>
<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Feb 5, 2015 at 11:03 AM,
"Thomas B. Rücker" <span dir="ltr"><<a href="mailto:thomas@ruecker.fi" target="_blank">thomas@ruecker.fi</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 02/05/2015 02:45 PM, Tony wrote:<br>
> I have an audio device driver for a live feed that
produces Opus<br>
> frames, if I were to use icecast, what sort of
real-time delay can I<br>
> expect? 3-5s? 5-10s? more?<br>
<br>
</span>Likely that or more. This highly depends on the
client side buffers.<br>
Icecast itself doesn't buffer much and that can be disabled
by turning<br>
off the burst-on connect functionality.<br>
HTTP streaming is not "real-time" for most values of real
time, it's<br>
still more "real time" than HLS thought, to my surprise.<br>
<span><br>
<br>
> I've tried using the html5 <audio> tag directly
to stream my source,<br>
> but it seems browsers like to queue-up 250K to 500K
of audio 'data'<br>
> before they begin playback. That introduces a 15-30s
delay depending<br>
> on browser and the audio compression used. I'd like
an html5<br>
> (plugin-less) solution that introduces no more than a
3-5s delay.<br>
<br>
</span>Yes, you can't control client side buffers for HTTP
based streaming to<br>
browsers.<br>
<br>
If you aim for something reliably <<5s without having
total control of<br>
the client side, then your best bet is to look at something
else. Maybe<br>
WebRTC?<br>
<br>
I'd probably be able to point out something more helpful,
but you don't<br>
state your actual use case.<br>
<br>
Generic standard comment:<br>
Most cases where people think they need an Icecast stream to
have a<br>
"low" delay are cases where some slight change in
approaching the<br>
problem would help. E.g. for collaborative streaming a real
time / VoIP<br>
backend that then streams to Icecast. Or in case of a
"internet radio" a<br>
question queue instead of trying to achieve "chat like
response" over<br>
the air, or rely on listeners actually "dialling in" through
e.g. VoIP<br>
for questions.<br>
<br>
<br>
Cheers<br>
<br>
Thomas<br>
<br>
<br>
<br>
_______________________________________________<br>
Icecast mailing list<br>
<a href="mailto:Icecast@xiph.org" target="_blank">Icecast@xiph.org</a><br>
<a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_blank">http://lists.xiph.org/mailman/listinfo/icecast</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div>Tony</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Icecast mailing list
<a href="mailto:Icecast@xiph.org" target="_blank">Icecast@xiph.org</a>
<a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_blank">http://lists.xiph.org/mailman/listinfo/icecast</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
Icecast mailing list<br>
<a href="mailto:Icecast@xiph.org">Icecast@xiph.org</a><br>
<a href="http://lists.xiph.org/mailman/listinfo/icecast" target="_blank">http://lists.xiph.org/mailman/listinfo/icecast</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">Tony</div>
</div>