<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">+1, yes many thanks Philipp. This is the exact talk that I was disappointed in missing out on so very valuable information.<div><br></div><div>Matt Morris.<br><br><div dir="ltr">Sent from my iPhone</div><div dir="ltr"><br><blockquote type="cite">On 30 Jun 2022, at 16:49, Dennis Heerema <dennis@heerema.net> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="auto"><div>Hallo Philipp,</div><div dir="auto"><br></div><div dir="auto">Thank you very much for sharing this.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Kind regards,</div><div dir="auto"><br></div><div dir="auto">Dennis<br><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">Op 30 jun. 2022 11:40 schreef "Philipp Schafft (phschafft@de.loewenfelsen.net)" <phschafft@de.loewenfelsen.net>:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><pre>Good morning,
over at Löwenfelsen we asked on LinkedIn what people think how low they
can go with Icecast and latency. As I think this is also interesting
for this list I want to share the results with you. Also going more
into technical details here as this list is more tech focused.
We asked what is possible?: Less than 10s, less than 1s, less than
100ms, or less than 10ms. What do you think?
So let's have a look:
There are a number of values that add up to the total latency.
The first one is the network latency. This is basically the time it
takes for any information to travel from the source to the sink
(listener) on the network. There are two limiting factors here: the
network access on both ends and the speed of light once you reached the
backbone level.
Network access delay depends very much on the network access technology
used (e.g. DSL, cable modem, power line, LTE, ...) as well as the ISP
and it's configuration. The values here dropped a lot. When I started
with Icecast it was more like 60..100ms in Germany now it is more like
2..10ms on wired connections.
In most cases your source client is connected via a good, nearly
backbone level network. So you can ignore that. However if you for
example have small studio that has just a consumer grade uplink you
need to keep that in mind.
Once you reached the backbone information will flow at about 1/3 of the
speed of light. It depends on where you are and where you want to send
to. But the above worked as a rule of thumb of me. So add about
1ms/100km.
You can consider this part of the latency unchangeable as it is
directly based on the physics of our universe.
There is a little more, see jitter a little later in this mail.
The next part is signal generation and rendering delay. This basically
means codec delays, delays of your sound hardware, delays of all the
other hardware (such as your RAM, your CPU, your PCI bus, ...).
This part is a bit under your control: You can use more modern
components and get a lower value. But all this also depends on both
physics and how we understand it. It is a area of huge amounts of
research and development.
So basically you add up all the numbers: sound card delay, sound card
interface delay, software delay, codec delay, network interface
delay,...
Most of those will be in the microsecond range so we can ignore it.
However sound cards, software, and codecs have a significant delay. At
least for codecs this got down a lot over the last 20 years. So
depending on your configuration you can reach values below 50ms.
The same applies for your listener. However e.g. codec delay which is a
large part of the source side's delay is normally much smaller on the
decoder side. But on the other hand you may not have that nice
processional sound card but something random adding more delay again.
Now there are two parts left, the delay by Icecast and the delay by the
listener software. So let's have a look at Icecast:
We had some tests (the results were in our last presentation) on the
delay within Icecast. Basically Icecast does forward data as soon as it
gets it. (I'm not sure where that myth Icecast would do some buffering
comes from.) But I think nobody really measured that before. So we did.
And in all our tests Icecast forwarded the data in less than 500µs. Now
please also keep in mind that this was done on multi-tasking operating
systems (both servers and desktops) so other things where going on as
well. Meaning that Icecast is subject of being blocked by other
processes as part of the normal operation of the operating system. And
this is what I have seen in the numbers.
What So the last significant part is the buffer in the listener client.
In reality this buffer is > 90% of the latency you get. Which is good
news actually:
If you control the listener client (e.g. the listener is using your
App) you are on full control over that buffer. So you can select any
value you like.
However there are a few limitations here to keep in mind:
* Network naturally jitters. The jitter is the difference in time it
takes for two packets to travel via the network. It is no delay by
itself as when summed up you will always get a sum of zero. However
for smooth playback the listener client must keep at least so much
buffer to handle the worst expected jitter. This is what that
listener buffer was made for initially. 20 years ago a value of e.g.
8 seconds seemed reasonable here. Today I would say that on wired
networks a value of 500ms..1500ms seams reasonable. Lower in
controlled environments.
* Mobile networks come with dead spots. The listener's buffer helps
with them as well as they look like jitter. Dead spots can be from a
few milliseconds to tens of seconds. So again: Select a value that
gives the best tradeoff for your usecase.
Bigger buffer: more
reliable, more delay
Smaller buffer: less reliable, less delay
* Browsers are very bad as media players. You will often have a hardtime to really control them. So just because you added a elements doesn't mean that you have playback under control.
So on the conclusion:
Icecast provides low latency forwarding of data. In the area of reliabl
e streams ("the music never stops") it provides the lowest latency
possible by laws of physics.
What latency you can expect depends on your setup and configuration.
Are you more optimistic? Or do you want to play more conservative? Do
you have your network, hardware, and listener clients under control? Or
maybe only parts of that? What kind of network anyway?
In reality It seems like the values you can get are around 20..500ms
plus the listener playback buffer (which can range from a few
milliseconds to a few seconds).
Also keep in mind that the numbers normally look much worse than they
are: Sound travels at about 343m/s (air, normal conditions). So every
ms more latency you have corresponds to someone sitting 34.3cm more
away from the speaker. So dancing to the music in your living room adds
another 15ms...
Hope this post was of interest. Also congratulations to everyone who
made it to the end.
If anyone is interested on how we measured it feel free to drop me a
mail off-list. Also if you're a CDN and want some measurements done or
have other questions, feel free to contact us as well.
With best regards,
--
Philipp Schafft (CEO/Geschäftsführer)
Telephon: +49.3535 490 17 92
Website: https://www.loewenfelsen.net/
Follow us: https://www.linkedin.com/company/loewenfelsen/
Löwenfelsen UG (haftungsbeschränkt) Registration number:
Bickinger Straße 21 HRB 12308 CB
04916 Herzberg (Elster) VATIN/USt-ID:
Germany DE305133015
</pre></div></blockquote></div><br></div></div></div><span>_______________________________________________</span><br><span>Icecast mailing list</span><br><span>Icecast@xiph.org</span><br><span>http://lists.xiph.org/mailman/listinfo/icecast</span><br></div></blockquote></div></body></html>