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.
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.
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
Ah, then my blunder. I saw comments about 64/128 sample buffers automatically tough that most packets will be in 128/256 bytes range where difference not that big.
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.
> 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.
> 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.
Right, that's what I meant. There will be some jitter depending on the scheduler, system load, network performance and traffic, and the quality of hardware/drivers; so more latency gives you headroom to absorb the jitter without underruns. The "ideal configurations" I was referring to were the low-traffic network and high-quality NIC. On a setup with more jitter, you might have to increase the buffer size (and thus latency) for reliable operation.
Mostly, I was just trying to contextualize the numbers for readers who aren't super familiar with low-latency audio networking. Sure, this project may not achieve the sub-1-ms roundtrip latencies that you can get with dedicated Dante hardware (like a Yamaha mixer and stagebox); but Dante can't do better than 8ms when one of the ends is a PC (although they were probably aiming for reliability on setups not aggressively tuned for minimum jitter.)
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.
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.
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.
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.
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.
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.
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.