+1, yes many thanks Philipp. This is the exact talk that I was disappointed in
missing out on so very valuable information.
Matt Morris.
Sent from my iPhone
> On 30 Jun 2022, at 16:49, Dennis Heerema <dennis at heerema.net>
wrote:
>
> ?
> Hallo Philipp,
>
> Thank you very much for sharing this.
>
>
> Kind regards,
>
> Dennis
>
> Op 30 jun. 2022 11:40 schreef "Philipp Schafft (phschafft at
de.loewenfelsen.net)" <phschafft at de.loewenfelsen.net>:
> 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
>
> _______________________________________________
> 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/20220630/c27dd8f1/attachment.htm>