alowell

I was just informed over email that there is a new piece of software for macOS called JackMoebius:

https://jackmoebius.io/

Assuming this works, this effectively replaces the broken JACK-Router driver. I’m looking forward to trying this out with ETH-68

Thank you very much for this comment. TBH when I made the post on r/linuxaudio, I figured there was a chance it would get drowned out by all the AI generated VST posts but fortunately that wasn’t the case

XLR and combo XLR/TRS tend to be significantly pricier, which matters since there are 14x in the BOM.

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.

Gotcha thanks. Just to be clear, the "high-quality NIC" is $20 on Amazon. The crappy TP-Link switch I'm using is also about $25. Achieving the ideal configuration takes little effort and money.

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.

In my comment that you replied to, I outlined a scenario where the only clock is the ETH-68 clock, so yes audio is sampled at the ETH-68 clock.

See my other comment in this thread about resampling with PipeWire or JACK.

Possibly. The STM32H7 Ethernet MAC does have IEEE 1588 support, although I've heard that it is not straightforward to use.

Not yet but actively figuring out what to do about that!

Nice project. Have you tried measuring the round trip audio latency on Linux?

But the packets aren’t small when streaming audio. The latency improvement is substantial for 1000 byte packets as the accepted answer in your SO post demonstrates

I’m aware they botched the 5532. But it’s gonna be a hard life boycotting all of TIs components

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?

Keychron, Q1 I think?

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.

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

Hm, the audio latency doesn't fluctuate so it's not like the testing conditions affect the measurement. The audio latency is a fixed quantity that depends completely on the number of storage elements in the data path which isn't variable.

Perhaps the better thing to focus on is the frequency of underruns (or "xruns" as they say on Linux, which also covers overruns) for a specific sample rate and buffer size setting. The histograms on my page (which should be animated BTW) show real time processing latency measurements while running the audio all the way through Bitwig with a moderate DSP load (multiple instances of Pianoteq, samplers, live MIDI input). On my system (details at the bottom of my page), I can do this at 48 kHz and 64 sample buffers with zero underruns. If I drop down to 32 samples per buffer, I do start getting underruns.

All I can do from the hardware side is try to minimize the processing latency of a typical cycle so that there is more head room to absorb jitter. The vast majority of the jitter comes from the Linux host. It's up to the end user to tune the system for low jitter. This is usually the case for audio on Linux, and the rabbit hole can go pretty deep on system tuning.

Oh thanks for that feedback, easy change.

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.

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.

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.

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.

Yep, thanks for clarifying about this!

You are confusing the audio latency with the processing latency. I see this mistake a lot.

One way audio latency is about 3.6 ms divided by two = 1.8 ms. This type of latency is audible.

Processing latency is just the amount of time it takes to complete all processing for each audio cycle. From the histograms, the typical processing latency is about 625 us and of course there is some jitter (almost all of the jitter comes from the Linux host BTW). Processing latency is not audible. However if the processing latency exceeds the deadline on a given audio cycle, there will be an underrun which will cause an audible glitch.

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.

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

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.

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

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.

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