[Icecast] On low latency

Thu Jun 30 21:05:49 UTC 2022

Same here. Very valuable so thanks for sharing this Philipp.

> On 1 Jul 2022, at 04:36, Matt Morris <mwpmorris at gmail.com> wrote:
> 
> +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
> _______________________________________________
> 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/20220701/9d8a2787/attachment.htm>