Very cool. However, I think I'm missing the usecase.
It needs a separate LAN, so basically it's audio over CAT6?
Don't get me wrong, I'm genuinely trying to understand.
How does this compare to pipewire over ethernet? Is it realtime vs buffered?
Don't get me wrong, I'm genuinely trying to understand.
How does this compare to pipewire over ethernet? Is it realtime vs buffered?
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.)
But this might be even more effective.
Besides audio dsp for live use, there is also the use case of visualizers.
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?
This enables me the watch video with no latency problems, because it's embedded in the audio stack (buffered). That's why I was wondering which problem gets solved with this project.
But now I understand that this is for concerts not for some audiophile multi room setup.
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. :)