Does PTP have an influence on audio quality - or do some switches "sound better"? Article by Oliver Ettlin on LinkedIn

[MaxwellsEq]

This is an article by Oliver Ettlin on LinkedIn: Does PTP have an influence on audio quality - or do some switches "sound better"?

In big media centres with thousands of devices communicating audio and video between each other at very low latencies, PTP (Precision Time Protocol) is used to "lock" everything together.

In this experiment, the network is ridiculously overloaded (no-one would run a media network this heavily loaded) and so PTP is deliberately made to be jittery when it gets to the final switch and networked audio device. They measured THD+N and found that "the measured impacts were not in the audible range".

Network switches with hardware PTP support were unaffected. Those network switches without hardware PTP support suffered from phase drift.

 

[amirm]

This test seems to be some kind of real-time playback, not the protocol we use for streaming (TCP/IP). In our use case, it is impossible to get those kinds of phase shifts. You will simply glitch if you run out of bandwidth.

 

[voodooless]

This is very specific to real-time audio protocols like AES67 and Dante, which rely on PTP to keep in sync.

Also, "phase shift" is wrong; it's a time delay, and it's not frequency dependent, though it might jitter over time.

They measured THD+N and found that "the measured impacts were not in the audible range".

Well, that is an understatement:

Generally, one would build a separate network or use VLANs to separate the audio traffic from all else, and then use QOS to make sure it gets priority above all else if it's a mixed infrastructure. But this is a fun test to show how resilliant this technology can be.

 

[MaxwellsEq]

This is very specific to real-time audio protocols like AES67 and Dante, which rely on PTP to keep in sync.

Also, "phase shift" is wrong; it's a time delay, and it's not frequency dependent, though it might jitter over time.

Well, that is an understatement:
View attachment 504589

Generally, one would build a separate network or use VLANs to separate the audio traffic from all else, and then use QOS to make sure it gets priority above all else if it's a mixed infrastructure. But this is a fun test to show how resilliant this technology can be.

This test seems to be some kind of real-time playback, not the protocol we use for streaming (TCP/IP). In our use case, it is impossible to get those kinds of phase shifts. You will simply glitch if you run out of bandwidth.

You are both absolutely correct. I perhaps should have added a few of my own observations:

1. If a person is listening domestically to a stream from, say Spotify or Tidal, even at 192/24 this "challenge" is not relevant, because everything is buffered and asynchronous to cope with the very wide range of loads and delays across the Internet (media centres using AES67, Dante etc. are not operating with any significant buffering)
2. If a person is listening domestically to a stream from a NAS, even at at 384/32 or 7.1 this "challenge" is also not relevant, again due to asynchronous working and buffering
3. Yes, it's they are discussing variable time delay, but at PTP level it could be detected as clock-phase shift - the author is focusing on how a distributed time protocol functions.

4. MOST IMPORTANTLY - real-time IP-based media-editing centres with thousands of devices in lockstep, operating with minimal buffering (to enable real-time switching, editing and mixing), are possible and actually exist. The current real-time IP media protocols only achieve scale when combined with distributed network time protocols. BUT even when things are as challenging as a massive media centre, NETWORK SWITCHES HAVE NO IMPACT ON SOUND QUALITY

So, for a totally unchallenging, domestic, asynchronous, buffered, non-real-time audio listening experience, this research can give confidence that network switches have even LESS impact on sound quality!

 

[EERecordist]

A long time ago I was deep into network and switch quality of service in standards committees. I bought international carrier backbone switches so I built a lab to study it with dozens of ports of traffic generators, receivers, and link error simulators. Non-blocking network fabric chips have been available for a long time. They are found in semi-pro switches in the story on up to 800Gb/s switches. Now they are seen in hyperscaler data centers. So from first principles, the test was unnecessary, as commenters have said. Where you have packet loss is in wireless. You can do forward error correction at a cost if that is an issue.

 

[Miley_B]

This AES paper from 2024 may also be of interest.

https://www.l-acoustics.com/wp-content/uploads/2024/04/ASR-2023-AVB-final.pdf