AES67 Audio over IP with Teensy/Arduino

Status
Not open for further replies.

recursinging

Well-known member
Hello all,

I was wondering if anyone has tried to, or put any thought into implementing support for the AES67 audio-over-ip standard for use with teensy/arduino? It seems like a very promising (albeit youthful) standard build on existing ones (rtp, ptp) with supposed <10ms latency. I found very little support for the standard in the open source world - GStreamer has an implementation/lib but it doesn't seem particularly portable (but I'm a Java guy and can't decipher c++ to well).

To give a little context, I'd like to build a digital guitar - Guitar Pickup -> Pre-amp circuit + ADC(Battery Powered I2S Optoiso) -> Teensy3.6+wiz850io -> PC AES67 Virtual Sound-card - with the whole apparatus built into the guitar body with RJ45+POE instead of your typical 1/4in analog output. This would make on-guitar controls for manipulating the PCM stream(s) with the Teensy+Audio library interesting.

I have a pretty good handle on how to glue most of what is necessary together to get my idea off the ground, but I'm a little stuck on AES67.

Any thoughts?
 
And why just AES67 over IP? Modern sound cards often have an optical input, so that you'd have just to add a I2S to TosLink converter to your Teensy and then have almost latency free hifi quality.
 
Oh I'm mainly just interested. I could do any number of transports, but AES67 seems a little like the holy grail, if you consider the success of dante and ravenna. I'm curious if the latency is not too high for monitoring.
 
And why just AES67 over IP? Modern sound cards often have an optical input, so that you'd have just to add a I2S to TosLink converter to your Teensy and then have almost latency free hifi quality.
Triggered by your comment, I did some internet search and found that going optical is disputed by some audio peoples (as it introduces some jitter) and only justified in heavy ground loop scenario.
( I do not want to start a spdif-toslink war, I only find it interesting)
 
To give a little context, I'd like to build a digital guitar - Guitar Pickup -> Pre-amp circuit + ADC(Battery Powered I2S Optoiso) -> Teensy3.6+wiz850io -> PC AES67 Virtual Sound-card

A cursory glance at the AES67 specification indicates the requirement for a PTP stack - so the Teensy 3.6 with native ethernet would be recommended instead of wiz850io.
(Teensy 3.6 has hardware timestamping support which is the crucial hardware feature required for a good PTP implementation)

I'm currently on the lookout for a PTP grandmaster clock so I can eventually do a minimalist PTP stack for Teensy.
 
A cursory glance at the AES67 specification indicates the requirement for a PTP stack - so the Teensy 3.6 with native ethernet would be recommended instead of wiz850io.
(Teensy 3.6 has hardware timestamping support which is the crucial hardware feature required for a good PTP implementation)

Ah, I think I understand, it seems that hardware timestamping allows compensation for the "resident time" spent in the stack itself, right? I wasn't aware this is a requirement/recommendation, I was under the impression that AES67 would work well on commodity hardware, but I suppose that's actually a question of how much skew is too much skew for the network/payload at hand. What I don't really grasp is why you might need a special grandmaster clock device to implement a PTP stack though, doesn't any elected master serve as grandmaster, or are there concerns about the accuracy of a device not designed for it?

I could have imagined taking on a RTP implementation, native ethernet on the Teensy 3.6... not so much. Back to the drawing board I guess.
 
I could have imagined taking on a RTP implementation, native ethernet on the Teensy 3.6... not so much. Back to the drawing board I guess.

I don't think it's too bad - take Paul's barebones code, add UDP and PTP support and you've got the bare essentials for messaging and synchronization.
(In the typical application for PTP - I don't see TCP as essential in the 1st version, you can do application-layer request-response messaging anyway)
https://github.com/PaulStoffregen/k66_ethernet

Later on, when/if there is an 'official' full stack, just add a PTP module to it.
 
Oh I'm mainly just interested. I could do any number of transports, but AES67 seems a little like the holy grail, if you consider the success of dante and ravenna. I'm curious if the latency is not too high for monitoring.

A virtual AES67 interface on the PC side will probably introduce too much latency. For really low latency you will probably need a dedicated AES67 interface. I have a Dante network with a Focusrite PCIe network interface and I tried the Audinate virtual interface but the latency is too high (~10ms) and it is limited to max 48kHz sampling rate. The PCIe network interface has a latency of just 150µs (there's one gigabit switch). The roundtrip latency for Logic X is 3.6ms at 96kHz sampling rate with a 128 samples buffer size.
IMHO a AES67/Dante network makes sense in the following cases:
- Multiple rooms or locations.
- Lots of channels needed.
- Maximum flexibility required (added channels, changing setup).
Of course you can do it just for the fun of it, then I would suggest you figure out a way to test the latency of the system before you start any actual construction. Another issue could be the cable, CATVI cable is not really flexible and this could be an issue when you hook up a guitar.

I do agree that AES67/Dante is the holy grail for serious studio quality digital audio distribution. I absolutely love it, it's rock solid and the flexibility is unparalleled.
 
A virtual AES67 interface on the PC side will probably introduce too much latency. For really low latency you will probably need a dedicated AES67 interface. I have a Dante network with a Focusrite PCIe network interface and I tried the Audinate virtual interface but the latency is too high (~10ms) and it is limited to max 48kHz sampling rate. The PCIe network interface has a latency of just 150µs (there's one gigabit switch). The roundtrip latency for Logic X is 3.6ms at 96kHz sampling rate with a 128 samples buffer size.

I wonder what contributes to the vast difference in latency between the focusrite and virtual interfaces. I assume the focusrite doesn't provide a general network interface to the OS, despite being an ethernet device. This would allow the driver developers to create a super optimized network stack, handle PTP with hardware, and pass the RTP payload directly to the ASIO interface/DAW.

The virtual interface on the other hand needs to work with the OS abstracted, general purpose ethernet device. It's destined to have worse latency, but your numbers give an idea just how bad.

I'm still curious though, if Teensys with optimized network stacks couldn't achieve similar latencies between each other as the focusrite hardware.

Regarding the Cat6 cable. I converted an old guitar into a MIDI controller and use Cat6 for MIDI in/out and power with a locking Neutrik cable, and it's definitely usable on stage.
 
I wonder what contributes to the vast difference in latency between the focusrite and virtual interfaces. I assume the focusrite doesn't provide a general network interface to the OS, despite being an ethernet device. This would allow the driver developers to create a super optimized network stack, handle PTP with hardware, and pass the RTP payload directly to the ASIO interface/DAW.

The virtual interface on the other hand needs to work with the OS abstracted, general purpose ethernet device. It's destined to have worse latency, but your numbers give an idea just how bad.

I'm still curious though, if Teensys with optimized network stacks couldn't achieve similar latencies between each other as the focusrite hardware.

Regarding the Cat6 cable. I converted an old guitar into a MIDI controller and use Cat6 for MIDI in/out and power with a locking Neutrik cable, and it's definitely usable on stage.

Indeed, the Focusrite card is not a general network interface but a dedicated Dante card with it's own CoreAudio/ASIO drivers. The card can handle 128 channels at 96kHz sampling rate and 24bit resolution. What I found most impressive was the sample delay if you patch in an external insert with the I/O plugin, so the signal goes out to the network is converted to analog routed through the outboard gear converted back to digital and transported through the network back into the DAW. Total delay is just 17 samples, this means the signal does not even go through the buffer in the DAW (128 samples) but is routed directly to the Dante card.
Audinate has special hardware to handle the networking, e.g. the Dante Broadway. I have no clue if these chips are available to end customers and what they cost.
If you can achieve this kind of latency performance with a Teensy that would be something.
 
Status
Not open for further replies.
Back
Top