How does the receive side recover the transmit side's sample clock? There is a BNC for clock sharing between "multiple units", but I'm not sure if that's used / required between transmit and receive.
Or is there no such synchronization, in which case there would be long-term drift?
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.
Yes this is an older codec but it has been reliably in production for around 20 years, and has a high channel count to cost ratio. The specifications are not cutting edge but I get comparable performance to my trusty Saffire Pro 40.
I have my eye on some other codecs for the next project.
Thanks for your interest! I made a single reddit post about ETH-68 this week and this has been copied around various forums. My intent was to figure out if anyone thought this would be cool enough to produce. I'm trying to figure out if I should do a production run, open source it, or some combo of the two.
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.
> 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.)
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.
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.
How does the receive side recover the transmit side's sample clock? There is a BNC for clock sharing between "multiple units", but I'm not sure if that's used / required between transmit and receive.
Or is there no such synchronization, in which case there would be long-term drift?
Hi, I'm Alex, I made ETH-68. I didn't create the post here on HN but I will answer some of the questions that have come up in the comments
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.
Yes this is an older codec but it has been reliably in production for around 20 years, and has a high channel count to cost ratio. The specifications are not cutting edge but I get comparable performance to my trusty Saffire Pro 40.
I have my eye on some other codecs for the next project.
How difficult would it be to extend it to 192kHz, or even 384kHz? Is it limited by the ESP32 hardware?
I'm using an STM32H7, not ESP32. The DAC on the PCM3168A can go up to 192 kHz, but the ADC can only be clocked up to 96 kHz.
For what application do you need 96kHz or 192kHz of bandwidth?
Don't forget about cats and bats, they like music too
Good old FM radio (in stereo) is a 192kHz mux, annoyingly.
How so?
Tuning into time radio signals like DCF77?
See also: https://news.ycombinator.com/item?id=3668310
What ESP32?
how do I buy this?
Or even build it. Strange there is zero info...
Thanks for your interest! I made a single reddit post about ETH-68 this week and this has been copied around various forums. My intent was to figure out if anyone thought this would be cool enough to produce. I'm trying to figure out if I should do a production run, open source it, or some combo of the two.
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.
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.
Dante’s default latency compensation is 1ms: https://dev.audinate.com/GA/dante-controller/userguide/webhe...
> 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.)
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
One can fit a nice (eg, not 1-channel, but actually useable) LTE base station frontend in a gigabit eth on 2014-s tech.
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.
> eth68 sends capture packets to 12.12.12.10:3000 by default.
Um.
Riiip…. I hate private projects pooping on public spaces.
At least it’s AT&T, not Huawei :)
> 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.
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 normally sub-ms.
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
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.
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.
Awesome. Love to see it!
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%