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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/icecast/attachments/20150205/162c388f/attachment.htm
"Thomas B. Rücker"
2015-Feb-05 16:52 UTC
[Icecast] Typically end-to-end 'delay' of live audio
Hi, On 02/05/2015 04:30 PM, Tony wrote:> 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.Ideally you'd mux both video and audio and thus establishing a strict relation between both. As it sounds you don't have that option (video happening outside the browser?) it becomes rather tricky.> 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.I'd probably look at webRTC (don't have experience but might be better suited or even able to consume what you have) or reusing that existing websocket and instead of feeding a plugin, feed it to a javascript based decoder. I've heard of emscripten based compiles working reasonably, but haven't tried it in a while (both audiocogs and libav I've noticed). You should also ask the opus mailing list. They might have better suggestions. Our event horizon is quite limited to HTTP here on this list.> 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.I'll disagree, fortunately they are fading away. I'm not entirely sure if everything that is moving in to replace them is good, but so far it doesn't look as bad as it used to be. I do realize though that the scientific community has come to rely on a variety of specific browser plugins and was a slow mover so far. I hope you get your specific use case sorted without going through too much pain. Cheers Thomas> > > 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 > 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 <mailto: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
Stéphane Benoit
2015-Feb-06 10:27 UTC
[Icecast] Typically end-to-end 'delay' of live audio
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 > <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 > 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 <mailto: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-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/icecast/attachments/20150206/03d5de42/attachment.htm
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-0001.htm