ETH-68: Ethernet Audio Interface for Linux (naturalsystems.io)
43 points by chabad360 a day ago
dasv 43 minutes ago
How difficult would it be to extend it to 192kHz, or even 384kHz? Is it limited by the ESP32 hardware?
hackingonempty 21 minutes ago
For what application do you need 96kHz or 192kHz of bandwidth?
oivaksef 15 minutes ago
Don't forget about cats and bats, they like music too
phaserphile an hour ago
how do I buy this?
askvictor 12 minutes ago
Or even build it. Strange there is zero info...
eqvinox 17 hours ago
> Very low latency: 3.620 milliseconds round trip at 48 kHz with 64 sample buffer
"very low latency" in audio is <=1ms. 3.6ms is good but not special.
tern an hour ago
Round trip latency for RME devices (widely considered the best in the industry) is around 3ms, so this is indeed "very low latency".
You might be thinking of latency of the converters, which is indeed normally sub-ms.
k_roy an hour ago
But it’s matching AND exceeding the performance of a $999 PCIe card designed for a similar purpose.
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 38 minutes ago
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.
k_roy 24 minutes ago
h3lp an hour ago
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
jauntywundrkind a 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.
dcrazy a day ago
Dante’s default latency compensation is 1ms: https://dev.audinate.com/GA/dante-controller/userguide/webhe...
altairprime a day ago
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.
Polizeiposaune an hour ago
> eth68 sends capture packets to 12.12.12.10:3000 by default.
Um.
k_roy 37 minutes ago
Riiip…. I hate private projects pooping on public spaces.
vasachi an hour ago
At least it’s AT&T, not Huawei :)