Thank you! You’re right, I didn’t discuss the MIDI implementation in the blog post. Right now it’s a little primitive but functional. Each MIDI message (e.g 3 byte note-on message) maps to 1 UDP packet. I have a simple script on the host side that interfaces these UDP packets with an ALSA loopback MIDI interface.
As someone who uses a USB equivalent to this piece of hardware (in my case, a Behringer UMC1820): having MIDI and audio inputs on the same interface is a nice convenience feature. Avoids needing to use up multiple ports on the host machine, and avoids a lot of the time synchronization issues that arise with trying to use multiple interfaces at once.
Well, it's certainly a dumb situation that I don't like that's created by my employer (and many others with similar setups), but it takes only two clicks to pick a category to make it available to folks behind these firewalls.
I went ahead and chose "blog" because it sounds like it's a blog. Apparently the "newly seen domains" category goes away on its own after 30 days, so that would have fixed itself, though then it would have been "uncategorized" and still blocked.
Yes. And no. The affected users usually have no control over the situation, so if the site owner cares at all that those people can't access it, then it is effectively their problem as they can potentially do something about it.
If neither party cares enough, then it is nobody's problem.
That's pretty much it. I wouldn't have mentioned it if not for the fact that it's easy to fix and for users it just looks like the site is down, which is not uncommon for small projects posted to HN.
I guess some people thought I liked cloudflare or something... that's definitely not the case.
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
I’m still working towards a first prototype, development has been slow due to my own schedule. But I’d expect round trip latency near what you’d expect from a USB interface. It would be cool to add ethernet support in the future though!
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.
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.
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?
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.
That is sort of true, although it should be possible to take advantage of the resampler in PipeWire or JACK (zalsa_in/zalsa_out) to effectively get multiple interfaces in the same graph. I would expect some hit to the audio latency when going through the resampler.
Unless audio is sampled at ETH-68 clock this won't work for long periods. Except if you are tuning a loop continuously doing continuous resampling using a Farrow filter for example.
If there were open source Dante that actually worked it would be very cool. Don’t know how much usage it would get since the hardware will always lock it in. But for small studios and research it might be cool. Interesting project nevertheless.
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.
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.
I'm curious what you mean about the STM32H7. My experience has been that it is a challenging part, at least partly due to bugs in the HAL. This is especially true for the ethernet implementation. But once it is working the performance is quite good.
Oh just the I used it in uni, made a design with it (though never assembled it-parts are still in a bag), and I've used it professionally for some years. The HAL certainly has bugs but they were easy to work around for me. That said, I've never used the Ethernet peripheral on it. And everything else has been easy enough for me to go direct register access if needed.
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.)
Afaik all pro audio standards more or less require ptp for timing, and that might add requirements for nics and switches? otoh the i210 nic, that is mentioned in the post, does have full (g)ptp/phc/tsn/etc support
I currently have a setup with a Raspberry Pi (alpine+pipewire+dac) to stream audio over the network.
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. :)
Distributing music != recording music != processing music.
There ARE good reasons for recording and processing music at higher bitrates and sample sizes. Effects, especially those with positive feedback loops, can go more unstable and clip and lose information with fewer bits and samples.
There's just no good reason to DISTRIBUTE music at the higher rates.
Don't such effects already upsample and downsample as needed internally ? You don't need to waste cpu on the effects that don't need higher sampling rate, right ?
They could. But then you get clipping effects and sampling effects when you convert back and forth.
Better to upsample once (generally a non-lossy operation) and operate on single precision FP (24-bit mantissa and an exponent) at higher sampling from that point forward and then downsample once (generally a LOSSY operation).
Stereo pair, pilot, RDS (the scrolling artist/song text), and the 67 kHz SCA. It's not quite 192kHz as I recall, but that's nearest fit really. AES192/192kHz MPX composite on the back end of every exciter/transmitter when I was last near them.
That's for the FM baseband signal, not the audio. Among other things you're doing here, you're basically treating a stereo signal (plus a pilot that effectively contains no information, plus an extremely low bitrate RDS stream in an extremely inefficient way) as one monaural signal.
But maybe there's a use case for replacing an AES192 signal carrying the full FM baseband signal over ETH-67? I'm not sure it's the correct fit, though.
That's how radio works now, it's owned by like 3 companies. Automation/playout for large groups of stations is all centralized, and they carry the baseband over IP to transmitter. Radio solved it awhile ago.
That's may be how the back-end of a modern broadcast FM radio transmitter works, but the good old stereo radio transmission itself still the same as it's been for many decades: It is analog, and mid-side encoded, and it remains completely compatible with monophonic receiver implementations.
Sorry, I was reading this late at night and must have misread the microcontroller. Then, the limitation lies in the codec and it would not be a minor modification or a matter of trading bit rate for latency.
I need to record ultrasound for work onboard construction vessels, currently we use either specialized equipment for PAM, which is limited in some aspects, or a USB sound card with a SBC and a hacky setup for sending PCM over TCP.
I would love this and am actively looking for a unit for my linux setup but: why the limit on sample rate? why not also support 44.1 kHz ?
How am I supposed to master for CD, which is still something people do?
Great to hear that you will support it in the future!
Sure, resampling works, but i only want to do it when it can't be avoided, not for basic playback.
If this had open source firmware, I think I know a lot of people who would be interested, but I can't seem to find out if that's true or not and where to buy one.
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.
I think this would be a cool project to do as a DIY.
The market for a linux native Audio Interface is there I think.
At least I for one would appreciate this!
I'm currently running 4x Echo Audiofire 12s in my Linux based Studio and something akin to what you are doing would be a much more fun and less expensive option than RME. Next version is 24 channel?? ;)
117 comments
https://radar.cloudflare.com/domains/feedback/naturalsystems...
I went ahead and chose "blog" because it sounds like it's a blog. Apparently the "newly seen domains" category goes away on its own after 30 days, so that would have fixed itself, though then it would have been "uncategorized" and still blocked.
Yes. And no. The affected users usually have no control over the situation, so if the site owner cares at all that those people can't access it, then it is effectively their problem as they can potentially do something about it.
If neither party cares enough, then it is nobody's problem.
P.S. By the way, to paraphrase an OS developer, Cloudflare, fuck you for "Sorry, you have been blocked. You are unable to access thunderbird.net".
I guess some people thought I liked cloudflare or something... that's definitely not the case.
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.
Or is there no such synchronization, in which case there would be long-term drift?
surely that works only as long as eth68 is the only interface? but often you might want other interfaces too which inherently have their own clocks
See my other comment in this thread about resampling with PipeWire or JACK.
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.
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...
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.
https://github.com/bondagit/aes67-linux-daemon
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. :)
There ARE good reasons for recording and processing music at higher bitrates and sample sizes. Effects, especially those with positive feedback loops, can go more unstable and clip and lose information with fewer bits and samples.
There's just no good reason to DISTRIBUTE music at the higher rates.
Better to upsample once (generally a non-lossy operation) and operate on single precision FP (24-bit mantissa and an exponent) at higher sampling from that point forward and then downsample once (generally a LOSSY operation).
But maybe there's a use case for replacing an AES192 signal carrying the full FM baseband signal over ETH-67? I'm not sure it's the correct fit, though.
https://www.telosalliance.com/radio-processing/audio-interfa... etc.
https://www.youtube.com/watch?v=hCQCP-5g5bo
A niche use, mind you.
Basically, I found myself doing real-to-complex baseband conversion for audio signals, and doing so efficiently halved my Nyquist rate.
Increasing my sample rate to 96 kHz let me construct the 48 kHz analytic signal that I wanted.
Hoisted on my own petard :)
I need to record ultrasound for work onboard construction vessels, currently we use either specialized equipment for PAM, which is limited in some aspects, or a USB sound card with a SBC and a hacky setup for sending PCM over TCP.
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.
Are you sure that's necessary? The STM32H7 has a decent fractional PLL.
How much do you think it'd cost if you were to sell and ship to the US?