ETH-68: Ethernet Audio Interface for Linux

  $ 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...

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.

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

I have my eye on some other codecs for the next project.

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

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.

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.

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.)

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?

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. :)

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.

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.

> 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

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.

You might be thinking of latency of the converters, which is normally sub-ms.

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.