[darkice] Re: Achieving realtime with streaming sound
- From: "Evert Verduin" <ebverduin@xxxxxxxxxx>
- To: <darkice@xxxxxxxxxxxxx>
- Date: Wed, 8 Dec 2010 00:45:04 +0100
Hi Roland,
Encoding takes time, in in order for the encoder to work ( mpg ) it needs to
"predict" sounds ( back in time with a buffer ).
There are encoders with milliseconds of delay, but consuming about 1,6
Mbit/s ( or more ), which are streaming raw data.
It's just not in the nature of mpg codecs to work with low latency. 1 Second
will pretty much be the boundary i think.
Telos systems has such devices, like the Axia IP boxes. Used in studios for
broadcast.
There are extreme low latency ( open source ) encoders like the CELT codec
( typ. 9ms delay ). http://www.celt-codec.org/ perfect for BROADCAST!!
@ Darkice team can the CELT codec be implemented ( in the future ? ).
BR
Evert
----- Original Message -----
From: "Roland Whitehead" <roland@xxxxxxxx>
To: <darkice@xxxxxxxxxxxxx>
Sent: Wednesday, December 08, 2010 12:33 AM
Subject: [darkice] Re: Achieving realtime with streaming sound
Evert,
On 6 Dec 2010, at 17:40, you wrote:
The highest quality will give you the lowest delay ( according to my
experience ).
Further, decrease your When buffer size in the player ( will increase
hickups in case of network issues. )
Many thanks for your reply. Of course the problem is that the higher quality
we deliver the more bandwidth we take up and when we are targeting mobile
platforms this isn't so hot. Currently we are streaming mono sound at a bit
rate of 160 as both .ogg and .mp3. listening via the command line with
mplayer and a cache of only 32K we get around 2 seconds of delay - 1 second
of which comes direct from darkice and appears to be the minimum. Different
browsers then cache different amounts and there doesn't yet seem a way of
controlling this. I'm still looking around for a way of controlling the
browser's cache but it isn't looking good - it's much easier with flash but
that is what we are trying to avoid! However, if darkice is always adding a
1 second buffer that represents 50% of our total delay (and with this delay
we are using an Amazon Web Services based Icecast2 server) then if we could
save 50% of darkice's delay we'd be saving 25% overall!
Furthermore, mpg encoding will always give some latency.
I know that now but surely there has to be a way of encoding the sound and
streaming it without delay...
Once again, many thanks for your reply. If I find an answer I'll post a
summary!
Roland Whitehead
--
QURU Ltd
Somerset House, Strand, London, WC2R 1LA
T: +44 20 7160 2888 DDI: +44 20 7160 2884 M: +44 7768 362669
Registered in England, No. 6144918, at Millmead, RH20 1AG.
Other related posts:
