Comment by jauntywundrkind
1 day ago
Really nice!!!
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.
1 day ago
Really nice!!!
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.
Dante’s default latency compensation is 1ms: https://dev.audinate.com/GA/dante-controller/userguide/webhe...
Brooklyn, IP Core can do 125us or 250us depending on number of switch hops.
> 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.)
> 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.
Hm, the audio latency doesn't fluctuate so it's not like the testing conditions affect the measurement. The audio latency is a fixed quantity that depends completely on the number of storage elements in the data path which isn't variable.
Perhaps the better thing to focus on is the frequency of underruns (or "xruns" as they say on Linux, which also covers overruns) for a specific sample rate and buffer size setting. The histograms on my page (which should be animated BTW) show real time processing latency measurements while running the audio all the way through Bitwig with a moderate DSP load (multiple instances of Pianoteq, samplers, live MIDI input). On my system (details at the bottom of my page), I can do this at 48 kHz and 64 sample buffers with zero underruns. If I drop down to 32 samples per buffer, I do start getting underruns.
All I can do from the hardware side is try to minimize the processing latency of a typical cycle so that there is head room to absorb jitter. The vast majority of the jitter comes from the Linux host. It's up to the end user to tune the system for low jitter. This is usually the case for audio on Linux, and the rabbit hole can go pretty deep on system tuning.
Yep, thanks for clarifying about this!
Sadly the H7 doesn't have a gigabit MAC. And most likely doing one over USB high speed host wouldn't help? But it would be an interesting experiment
https://semiengineering.com/latency-considerations-for-1-6t-...
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.
1G would certainly decrease the processing latency (not the audio latency) by quite a bit. STM32H7 doesn't have a 1G MAC. 1G MAC is kind of rare on "friendly" microcontrollers, although there are at least two that I'm evaluating for the next project.
One can fit a nice (eg, not 1-channel, but actually useable) LTE base station frontend in a gigabit eth on 2014-s tech.