It seems like, at 16000TbaseT anyways, you’re adding an overhead of about 150% on top of copper/fiber latency plus transmit time latency to process data at that bandwidth. I wonder if the same holds true at 100 vs 1000, 2500, 10000? Certainly this is a known tradeoff for DDR performance tuning — if you don’t mind spiking response times greatly, you can get the advertised maximum speeds, else you accept less bandwidth for somewhat less latency — and they’re both effectively using the same strategies to talk over copper.
> The typical default latency for a Dante audio device is 1 msec.
(emphasis mine)
The latency depends on the device. Hardware implementations of Dante commonly support latencies of 1ms or less, but software implementations are higher. The minimum latency of Dante Virtual Soundcard running on a PC is 4ms.
That's the appropriate number to compare against here (since the PC is using a software driver to interface with the network). However, that 4ms number is one-way latency, and the OP's 3.6ms number is round-trip. So this is already half the latency of DVS. (That being said, it sounds like this latency figure was only achieved in very ideal configurations, and we don't know the reliability/rate of late packets compared to DVS.)
They quote a roundtrip of 3.6ms, so one-way 1.8ms. In the plots on their page, it looks like the processing latency is centered on around 1ms:
> The LATMON pulse width is therefore an accurate measure of the total processing latency of each cycle and is affected by every element in the data path: processing delay in the microcontroller, network transmission delay, host OS delays, signal processing delay in the DAW, etc
As the owner of the PCIe card that measurement was taken from, yes, I’d say it’s quite impressive. The average round-trip latency for a USB audio interface at 48 kHz/128 samples would usually fall somewhere around 8 ms, which is a bit much if you’re monitoring post-FX.
On Linux, we don’t have much in the way of Thunderbolt support for audio interfaces, so the only way to achieve this sort of latency has traditionally been with PCIe or PCI audio interfaces. Having a low-cost, infinitely more portable solution would be very welcome.
Far be it from me to discourage an H7 build, but I do question the codec choice. It's far from top of the line and it's not like the design is tight on space. TI offers much better (almost 20 dB SNR more on the ADC). Maybe a gen 2 could benefit from a better codec.
How does the receive side recover the transmit side's sample clock? There is a BNC to clock sharing between "multiple units", but I'm not sure if that's used / required between transmit and receive.
jauntywundrkind | a day ago
I wonder if gigabit would make a difference on latency, faster packet transmissions. Could packets drop from 64 to 32b?
4ms is pretty good but I feel like sub 2ms would be nicer.
altairprime | a day ago
It seems like, at 16000TbaseT anyways, you’re adding an overhead of about 150% on top of copper/fiber latency plus transmit time latency to process data at that bandwidth. I wonder if the same holds true at 100 vs 1000, 2500, 10000? Certainly this is a known tradeoff for DDR performance tuning — if you don’t mind spiking response times greatly, you can get the advertised maximum speeds, else you accept less bandwidth for somewhat less latency — and they’re both effectively using the same strategies to talk over copper.
dcrazy | a day ago
NobodyNada | 36 minutes ago
(emphasis mine)
The latency depends on the device. Hardware implementations of Dante commonly support latencies of 1ms or less, but software implementations are higher. The minimum latency of Dante Virtual Soundcard running on a PC is 4ms.
That's the appropriate number to compare against here (since the PC is using a software driver to interface with the network). However, that 4ms number is one-way latency, and the OP's 3.6ms number is round-trip. So this is already half the latency of DVS. (That being said, it sounds like this latency figure was only achieved in very ideal configurations, and we don't know the reliability/rate of late packets compared to DVS.)
Neywiny | 27 minutes ago
eqvinox | 18 hours ago
"very low latency" in audio is <=1ms. 3.6ms is good but not special.
h3lp | 2 hours ago
> The LATMON pulse width is therefore an accurate measure of the total processing latency of each cycle and is affected by every element in the data path: processing delay in the microcontroller, network transmission delay, host OS delays, signal processing delay in the DAW, etc
k_roy | an hour ago
I would love to know why this is hand-wavy and not very cool? Even as not-audiophile, I’ve got ideas of things to use this for.
> RME HDSPe AIO Pro PCIe
> eth68 matches the latency performance of the RME card at 48 kHz and surpasses it by 0.33 ms at 96 kHz.
Venn1 | an hour ago
On Linux, we don’t have much in the way of Thunderbolt support for audio interfaces, so the only way to achieve this sort of latency has traditionally been with PCIe or PCI audio interfaces. Having a low-cost, infinitely more portable solution would be very welcome.
k_roy | an hour ago
This is just the answer I was looking for. I definitely don’t know anything about the audio space, but am into networking hardcode.
I love seeing audiophile projects that don’t involve a rebranded tp-link switch and marked up 1000%
tern | an hour ago
You might be thinking of latency of the converters, which is normally sub-ms.
Polizeiposaune | an hour ago
Um.
vasachi | an hour ago
k_roy | an hour ago
phaserphile | an hour ago
askvictor | 54 minutes ago
dasv | an hour ago
hackingonempty | an hour ago
oivaksef | 57 minutes ago
cbm-vic-20 | 35 minutes ago
tacos8me | 31 minutes ago
anyfoo | 18 minutes ago
thomasjb | 30 minutes ago
Neywiny | 29 minutes ago
Neywiny | 26 minutes ago
jhallenworld | 8 minutes ago