7 Sep
2010
7 Sep
'10
1:39 p.m.
'Owdo again!
Now that I've icecast running with ices as a feeder, I wonder, if I can turn
down latency. In icecast I set the burst-size to 0 and in ices I set realtime.
Still the delay is considereable. Is there any chance of tuning this setup
further to reduce latency?
If it helps, I will post my ices.xml and my icecast.xml.
Kindly yours
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
8 Sep
8 Sep
2:19 a.m.
On 09/07/2010 01:39 PM, Julien Claassen wrote:
'Owdo again!
Now that I've icecast running with ices as a feeder, I wonder, if I
can turn down latency. In icecast I set the burst-size to 0 and in ices
I set realtime. Still the delay is considereable. Is there any chance of
tuning this setup further to reduce latency?
The setup of the receiving client matters also. I have used the
combination ices->icecast->ogg123 for streaming over the internet with a
latency of ca. 3-4seconds, which is worse than what you get. But the
three processes were on three machines with the internet in between, and
the receiving side was connected using CDMA.
The crude tweaks I used to get latency down, were:
In ices.conf:
- use a high bandwidth, so any buffers along the way are filled up
faster. I used 320kbit/s.
In icecast.xml:
- set burst-size to 0, just as you did
With ogg123:
- chose a small input buffer. I used:
$ ogg123 -b 8 http://users.notam02.no:8000/bells.ogg
and got dropouts, and then I used
$ ogg123 -b 16 http://users.notam02.no:8000/bells.ogg
and run without dropouts for 30minutes.
One problem I saw, was that drifting of the clocks caused the buffers
either to be emptied or to be overfilled after a while - depending on
which soundcard was the faster one.
/ Hans
-----
Hans Wilmers
NOTAM
Nedre Gate 5
N-0551 Oslo Norway
tlf.: +47 22358065
http://www.notam02.no
2:32 a.m.
Hallo Hans!
Thanks very much. I think I'll try that and see how far I get. At least here
both ices and icecast are on the same machine.
Kindly yours
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
9 Sep
9 Sep
7:37 p.m.
On 09/07/2010 01:39 PM, Julien Claassen wrote:
'Owdo again!
Now that I've icecast running with ices as a feeder, I wonder, if I can
turn down latency. In icecast I set the burst-size to 0 and in ices I
set realtime. Still the delay is considereable. Is there any chance of
tuning this setup further to reduce latency?
If it helps, I will post my ices.xml and my icecast.xml.
the latency is usually bounded by the client buffer.
additionally, it can be irritating that streams that start with silence
seem to exhibit immense latency. the reason is that the size of the
client buffer is usually not defined in seconds but in bytes. ogg vorbis
for example tends to encode silence at very nearly 0 bit/s, so you can
imagine it takes a while for a silent stream to fill the client buffer,
and any subsequent programme material will appear to be severely delayed.
doing away with client buffering is dangerous, because it makes the
client very susceptible to drop-outs.
as to the burst-size, it can be useful, too. say you have a burst-size
of 64kbyte at 128kbit/s, that means the server will push out the data
from (now - 4s) to (now) in one burst transfer. if your client has 64
kbytes of input buffer, it will have a playback latency of those 4 s,
but it will start playing *now* (thanks to the burst filling its buffer
almost immediately). that can improve the user experience.
so unless you don't use client buffering at all, burst-sizes >0 will
generally not cause extra latency.
7:52 p.m.
Hello Joern!
So if I set the ogg encoding to cbr could I push down latency?
I'm trying to build a simple p2p communication, since nothing else has
worked so far. Though I'm giving netjac (jackd -dnet) another go now as well.
Still it's good to have several alternatives. :-)
Kindly yours
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
10:46 p.m.
Hi,
You have also to notice that, in the case of a _none_ PCM music streaming format
like mp3 or ogg, the encoder usually needs several input buffers to process its
own frequency, amplitude analysis and then matricing. So, whereas the size of
this chunk is varying with the bitrate and the requested quality, it is
impossible to get a very low latency between the (PCM) source and the
broadcasted stream sent to the icecast server (+ the icecast's own buffer).
But, if you _really_ need some low latencies and bitrates, checkout this codec
which tends to reduce those latencies drastically:
http://www.celt-codec.org/
I don't know, however how this codec is supported by main players...
Who knows ? Would this be also streamable through icecast nodes ?
Cheers,
Yomguy
Le 09/09/2010 19:35, Jörn Nettingsmeier a écrit :
On 09/07/2010 01:39 PM, Julien Claassen wrote:
'Owdo again!
Now that I've icecast running with ices as a feeder, I wonder, if I can
turn down latency. In icecast I set the burst-size to 0 and in ices I
set realtime. Still the delay is considereable. Is there any chance of
tuning this setup further to reduce latency?
If it helps, I will post my ices.xml and my icecast.xml.
the latency is usually bounded by the client buffer.
additionally, it can be irritating that streams that start with silence
seem to exhibit immense latency. the reason is that the size of the
client buffer is usually not defined in seconds but in bytes. ogg vorbis
for example tends to encode silence at very nearly 0 bit/s, so you can
imagine it takes a while for a silent stream to fill the client buffer,
and any subsequent programme material will appear to be severely delayed.
doing away with client buffering is dangerous, because it makes the
client very susceptible to drop-outs.
as to the burst-size, it can be useful, too. say you have a burst-size
of 64kbyte at 128kbit/s, that means the server will push out the data
from (now - 4s) to (now) in one burst transfer. if your client has 64
kbytes of input buffer, it will have a playback latency of those 4 s,
but it will start playing *now* (thanks to the burst filling its buffer
almost immediately). that can improve the user experience.
so unless you don't use client buffering at all, burst-sizes >0 will
generally not cause extra latency.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
11:15 p.m.
Hello Yomguy!
I tried to experiment with direct small toolchains as well and noticed, that
ogg encoding takes a little time. Even speex took some time, alth9ough it was
better. I know, that celt is used for netjack, which accidentally still
doesn't work the way it should :-) Yet thanks for the info. I'll see how
mplayer handles celt or a simple pipe of the celt decoder and some other basic
player.
Kindly yours
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
5249
days inactive
5251
days old
linux-audio-user@lists.linuxaudio.org
6 comments
4 participants
participants (4)
-
Hans Wilmers -
Julien Claassen -
Jörn Nettingsmeier -
Lists Parisson