AES 67 Driver

[ReubenM]

This topic has been tossed around on several mailing lists, but nothing has ever come from it. I want to start an actual request here for an AES 67 backend driver for jack.

Personally I want to be able to multitrack audio from a Yamaha based Dante system that offers AES67 as an interop protocol format.

I believe all functionality is available from various FOSS libraries, and it should mostly be a matter of creating code to glue it together.

Some Details:

• Discovery
  • SAP / SDP
  • sap.mcast.net (224.2.127.254:9875)
• Audio streams
  • RTP Multicast (239.69.0.0 - 239.69.255.255/16)
  • Up to 8 channels per stream
  • 24bit 48kHz
• Clocking
  • Slave to PTP master network device
  • both IEEE 1588 v1 & v2 need to be supported since there can be a mix of both

ffmpeg project libraries support both SAP and RTP. Also there are several FOSS PTP implementations available.

Yamaha Documentation

If anybody wants to take a stab at this I can provide a powerful gentoo box you can remote into, connected to a yamaha dante network outputting AES 67 for testing.

[wargreen]

Hi, i'm very interested also !
Ravenna seem work on a alsa driver : http://forum.merging.com/viewtopic.php?t=11319#p39464

we are working on an AES67 ALSA driver and we are close to finalize.

[chris-ritsen]

Audinate just released some new adapters (AVIO) which support two channel in / out and over XLR and USB. The USB adapter appears as a standard audio device, so this works with jack using alsa_in / alsa_out. I have these connected to a d-link dgs-1510-28p switch. Once I figured out how to configure DSCP, everything worked perfectly. I recommend these to anyone who wants relatively inexpensive Dante/AES67 hardware to get started. Latency is averaging about half a millisecond per adapter and all of the IO is balanced.

[ReubenM]

There is also a PCI-E Dante / AES67 card that has come onto the market recently which explicitly states that it has Alsa driver support: https://www.digigram.com/production-and-sound-cards/lx-dante-ip-audio-network-multichannel-sound-card/

[edglazer]

FWIW, Audioscience has a number of cards that support some of the individual specs that are wrapped into AES67 - specifically AVB, Livewire (Ravenna is very close to Livewire, IIRC), and Cobranet. http://www.audioscience.com/internet/products/network_audio.htm

Further, they have downloadable driver source code for their devices: http://www.audioscience.com/internet/download/linux_drivers.htm

Maybe that is helpful to someone?

[edglazer]

Also this is an example of someone working towards the same: https://github.com/markmcconnell/mai
And this project has apparently implemented functional Ravenna/Livewire AES67 as a source and a destination on the network: https://github.com/openbroadcaster/obplayer

[ghost]

@edglazer ,
could you advice me the working source code with implementation of AES67. I want to realize it on ARM-MCU.

[edglazer]

@edglazer ,
could you advice me the working source code with implementation of AES67. I want to realize it on ARM-MCU.
I probably can't offer much help, I've only patched together very basic AES67 applications on a network. And actually, they are probably not, technically speaking, true AES67 implementations, because they use the Livewire protocol (the Telos AOIP implementation), and not their slightly newer AES67 compliant "Livewire+" protocol.

You might want to check out Archwave, a company that develops SoCs for AES67 & 70. Also Ravenna offers various software, and I think they partner with others to develop products for AES67. I have an email from 2015 where they said:

The software is designed to run on any Linux-capable hardware platform (i.e. ARM9, PowerPC, Intel PC etc.). Most of the code is platform-independent, but apparently the platform needs to supply certain functionality (i.e. drivers, Linux board-support package etc.).

I never got much further in talking with them, but I believe their model is to partner with developers and help them write code to use Ravenna/AES67 (in exchange for money, I'm assuming).

Hope that is helpful!

[ghost]

Thanks you for answer.
Could you send me an email-address of Ravenna?

[paraenggu]

@vadly67 Some (hopefully) interesting mail-threads and links regarding AES67
Basically the GStreamer project has all components ready for an implementation but would need someone to glue them together into a working client (see the Darkice link below).

• AES67 publication (download is subjected to a charge of $100.00 for Non-AES-Members)
• Telos Alliance and Livewire+/AES67
• Discussion about Darkice and AES67
• Discussion on the Jackd mailinglist regarding AES67

BTW. we at Radio Bern RaBe would love to see a working open-source implementation of AES67 and are happy to test or otherwise contribute :-)

[ghost]

@paraenggu, thanks a lot for links

[ghost]

I applied mai master (as sender). But I have big problems with Jack Kit. This Kit give very big noise.

[edglazer]

@vadly67 I think I just emailed the address on their contact page.

[edglazer]

Wow, I just noticed that Merging Technologies has produced an ALSA AES67 driver for Linux, and the source code is available in this repo. That might be helpful?

[edglazer]

@vadly67 I also found this example of someone who wrote a functioning open source implementation of a gstreamer based AES67 recorder. https://github.com/voc/aes67-recorder

You never said what your use case was, just that you wanted it to run on ARM. Maybe if we knew more about your specific application, we could point you more specifically in the right direction.

[ghost]

@edglazer ,
thanks you a lot.
My finish aim - creating AES67 devices which based on ARM MCU. For intermediary step I selected implementation of mai-master ( https://github.com/markmcconnell/mai ) on Ubuntu (PC).

[bvanpoortvliet]

@vadly67
I think I'm trying to accomplish the same, a send/receive AES67 on raspberries with MAI. Any progress on your end so far?

[ghost]

@edglazer,
I almost finished it on Ubuntu. I have used Jack audio but noise of reproduced signal is more then average.

[edglazer]

@vadly67 That's interesting, but strange. This is on a PC with Ubuntu, right? Can you isolate where in the audio chain the noise is being introduced (including the networking stack)?

[ghost]

@edglazer,
I checked it in the next chain: microphone-> mai-> rtp packets which immediately was saved on disk in the sound file. After reproducing of this file I listened sound.

[ghost]

@edglazer,
Possible the sound quality was not good because mai- application does not use PTP sync?
If you have experience, could you say about using precise time received from PTP Grand Master:

1. adjustment the system clock
2. adjustment the clock of audio driver (ALSA, Jack and etc.)
   What is method using for time adjustment : only first or first and second methods?

Thank in advance

[edglazer]

@vadly67 I don't have experience with the setup you are using, and I'm no longer working at the same place I was when we started commenting on this thread. Unfortunately I don't have access to AES67 compliant hardware at this time.