Is this open source? I’ve been working on https://codeberg.org/olpad/openmic which is in the more traditional domain of USB audio interfaces, but I’d be interested in taking a look at the internals of the ETH-68

Thank you for taking the time to write up the work properly. It's quite refreshing to read content like this after what's been the standard fare that's been posted here at HN.

First off, very cool project and great article showcasing it! Why does it also have MIDI?

Is it actually for sale or otherwise obtainable?

hello Alex,

tech nerd/musician here, I would be very interested in this! do you have an email list or something I can sign up for? this is fantastic, and if the $$$ is not crazy, I would want this for sure.

What's your use case where you want more outputs than inputs? At home I run a Audiofuse 16Rig with a lot of ADAT expansion to get 32i/32o, but I only use like 6o, while every input is used.

FYI your domain is marked "newly seen" on cloudflare, which results in it being blocked by Ubiquiti Unifi domain filtering.

  $ dig NS naturalsystems.io @1.1.1.1
  [...]
  ;; WARNING: recursion requested but not available
  [...]
  ;; AUTHORITY SECTION:
  naturalsystems.io.      3600    IN      SOA     block.unifi.local. 0. 7200 900 1209600 86400 0

https://radar.cloudflare.com/domains/feedback/naturalsystems...

Might you do clock synchronization via PTP in the future?

Unrelated question: what is the keyboard on the last picture of the post?

Why not XLR?

I think I'm going to have to make a blog post addressing some of the clocking questions that come up. My brief answer for now is that there is only one clock, and that is the ETH-68 clock. The overall data flow is push based; the arrival of a new buffer of data at the Linux host IS the clocking event that schedules an audio graph evaluation. There is no need for another clock on the Linux host.

Seem like a link to a Pipewire repo. Instead it is a Pipewire implementation of Milan-AVB.

Milan-AVB is a deterministic, standards-based media networking protocol built on top of Audio Video Bridging (AVB) and Time-Sensitive Networking (TSN) IEEE standards. Maintained by the Avnu Alliance, it is designed for the professional audio, video, and live event industries to guarantee plug-and-play interoperability across devices from different manufacturers

After the whole drama about TI opamp, i would never trust any components from them.

Edit: For the context: https://www.eevblog.com/forum/chat/ti-ne5532-audio-opamp-cha...

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.

Dante’s default latency compensation is 1ms: https://dev.audinate.com/GA/dante-controller/userguide/webhe...

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

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.

gigabit have throughput, but not latency. For small packets and on low load link there will be almost no difference (i had better source: https://serverfault.com/questions/276651/network-latency-100... , ethernet cnc controllers have same problems). It needs to go 10gbps or even 25gpbs to see lower latency, where electrical signal uses much higher electrical signaling bandwidth.

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.

One can fit a nice (eg, not 1-channel, but actually useable) LTE base station frontend in a gigabit eth on 2014-s tech.

There is AES67 support in PipeWire as of 1-2 years ago. I've tried it with some Dante hardware that I own, running the hardware in AES67 mode. It didn't work very well for me, even after lots of fiddling. If the experience would have been better, I probably would not have started working on ETH-68. It might be better now, I hope that it is.

ETH-68 doesn't have nearly as broad of scope as AES67. It is a much simpler system, so easier to realize for a 1-person team working on weekends.

Just a few other comments: 1. AES67 usually means Dante hardware which is notoriously expensive. 2. Dante devices running in AES67 mode often (always?) have their capabilities reduced. At least in some cases you are limited to 48 kHz, and I believe you are also limited on latency compensation settings. Someone with more experience could chime in.

There's also AVB but it also requires some specific functionality from network switches...

It's a hardware audio interface with a very low latency (buffer of 64 samples, 3.6 ms), which supports both PipeWire and JACK over Ethernet, as shown on the pictures in the post. It's audio over CAT6, and a lot of it, 6 inputs + 8 outputs (TRS balanced) at 48 or 96 kHz.

Imagine having this on the stage right next to your analog gear, and a computer 50m away.

(Opening the page under discussion was actually helpful, it lists all this right at the top.)

It doesn’t need to be a separate LAN. But using a dedicated LAN helps to keep extraneous traffic from delaying time sensitive audio packets.

ETH-68 isn’t running PipeWire, or Linux. Maybe I don’t understand your question.

Not sure what you mean by realtime vs buffered. Care to elaborate?

Some background on the utility:

Pro audio systems frequently (and increasingly) use networked audio. Some obvious uses are distributing the sound from the instruments and people on a stage over to the front-of-house mix position that's usually somewhere mid-crowd, and also to the monitor mix position that's usually in a vaguely-quieter area off to the side of the stage, and to the broadcast truck.

The old tried-and-true method also still works: Analog splits. Take a bunch of audio sources (eg, microphones) and plug them into passive stage boxes that output over a thick-ass cable. Those thick-ass cables go to larger passive split boxes (often on wheels by this point), with two or more outputs for even-thicker cables, with one pair of wires for every individual signal -- often with individual shielding and jacketing.

Eventually, these splits can deliver audio to the different places that need it -- where it's ultimately broken back out into a bazillion individual cables that get plugged into things like mixers.

The cables can be very long (hundreds of meters) in length, and extremely heavy. They're expensive to produce, they're expensive to maintain, and they're expensive to wrangle. They often get transported in their own dedicated wooden trunks. But at least it's simple: A bunch of different audio devices scattered all over a venue, wired in parallel, listening to the signals that are directly produced by microphones on a stage.

---

But with networked audio, it can be more like this: A few boxes on a stage that accept analog audio on one side and emit network frames (often Ethernet or Ethernet-adjacent, and actually using IP isn't a rule at all) that contain digital audio on the other side. Those frames go to a network switch. One or more tiny-ass network cable comes out of the switch and goes wherever it needs to go, and switches can be cascaded, and more audio channels can be added downstream. Because Ethernet(ish) is a many-to-many network, it's bidirectional, too: Audio signals can go upstream just as easily as they go downstream.

It's tidy. It works. It's still expensive because the endpoints are expensive, but the cables themselves can be fairly inexpensive (think robustly-built Cat6 or fiber patch cords instead of giant cable trunks). If the venue's infrastructure goes to the right places and can be trusted, then it can also be used: Plug the stuff from the stage switch into a fiber patch panel on the building, and plug the broadcast truck outside into the same building, tie them together in some MDF or IDF somewhere, and send it. (And in a pure and just world where dedicated fiber links both exist and are easy: Patch another into the studio downtown. Or route it over an IP link that is shared with other purposes, if appropriate and also feeling brave.)

But with the tidiness comes complexity. Like... Latency is kind of a big deal here in ways that aren't a practical issue with analog audio. Putting too much delay between a vocalist and the monitors that they hear themselves with is actively deleterious of their ability to sing, for example.

And buffers are still required (they're ~always required when packet-switched network frames get converted to continuous analog signals). Keeping the buffers small requires very tight timing signals that get shared between all points. Pre-existing systems often achieve that with things like Precision Timing Protocol (though variations exist).

That all conspires to mean that the heavy lifting at the endpoints is often in the realm of FPGAs.

But, again: We get many channels over some bog-standard network cabling. Dante, for example, can be used to transport hundreds of 48KHz 24-bit audio channels on one gigabit ethernet link.

---

Anyway: This is a cheaper, smaller method. It uses an STM32H7 microcontroller to convert betwixt the network transport stuff and the DACs and ADCs of the analog world. It's designed to be used with the open-source Jack system that is commonly-used internally whenever Linux gets involved in recording or stage use, so it's simple to integrate with a Linux PC running software like Reaper. And at the end of the day, it's transportable over the Ethernet networks we all have.

And despite being built around an STM32, it achieves quite usable latency: The stated 3.620ms is about the same as a 1.2 meters of distance for sound in air.

Neat stuff. I'll probably never use it, but it's neat. :)

And yes, I know there are newer USB adapters which are supposed to be able be able to help, like FPT (which I may have tried, can't recall), along with playing with ASIO settings. Since the problem was "solved", I never really got far down that rabbit hole. Also wary of getting into troubleshooting/isolating effects of my USB driver/software stacks (that I suspect introduced some unrelated known issues on certain older motherboards), the generation of the USB standard it's plugged into, extra levels of PCIe expanders gating the ports I'm using, contention from competing devices on the same bus, etc. Maybe these are groundless concerns but I figured there may be more variables involved vs. an Ethernet jack that has a comparatively direct hardwired connection to my bus (maybe through 1 expander). I can accept I might just be an old fart who needs to try again on more modern hardware/stacks.

I have done a small amount of work on macOS but it is not a priority. I did some preliminary work with this nice library:

https://github.com/gavv/libASPL

I have also thought some about whether or not I could make BlackHole work.

My takeaway so far is that macOS is more of a hassle for developing this stuff. It doesn't help that CoreAudio is not open source and the docs are hard to navigate. Hopefully someone will fix JACK-router on macOS one of these days.

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?

What ESP32?

The next Rev will have an additional oscillator to support 44.1/88.2.

Just curious though, since I don’t work at these sample rates. Is resampling not good enough? Or maybe I don’t understand the mastering flow.

Or even build it. Strange there is zero info...

Riiip…. I hate private projects pooping on public spaces.

At least it’s AT&T, not Huawei :)

Lol, this wasn't my choice really! The JACK server's default UDP listen port is 3000 with the netone backend, so that is default port that ETH-68 sends to. This can be adjusted on both ends

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.

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.

Check out the round trip latency measurements for audio interfaces on Linux here:

https://interfacinglinux.com/linux-compatible-audio-interfac...

AFAIK the best one is RME AIO Pro PCIe card. ETH-68 matches the round trip audio latency of this card at 48 kHz and surpasses it be 0.33 ms at 96 kHz.

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