AES67 Implementaitons on FGPA or Microcprocessor

[mrpackethead]

Has anyone seen anything opensource for an AES67 interface in micro or FPGA?

[dmills]

One of the Linux audio tools (Gstreamer?) will play an AES67 stream (It considers it to be RTSP as I recall), but the elephant in the room is clocking, being as to really do this right you need the PTP clock to also be driving the converter clock.

We are looking at doing the FPGA thing at work, does not look overly difficult, but I just wish AES 67 included enough bloody metadata in the stream itself to allow you to figure out the details given just a multicast address, having to use SAP/SDP is annoying.
Remember you will have to generate the IGMP join and leave messages for the subscription, and that is not always entirely obvious if you read the RFCs in detail.

There is also fun in that some of the AES67 implementations expect PTP V2 and some V1! Audinate, looking at you!

Are you looking for full fat AES67, or just the SNPTE profiles per say SMPTE 2110?

Regards, Dan.

[coppice]

They just reused well established standards - uncompressed PCM in RTP for the audio data, and PTP from IEEE1588 to get the timing precise - so they ended up with all the strengths and weaknesses of that scheme. In most systems there isn't much metadata available at the point where the stream is formed, so it couldn't be included anyway.

[dmills]

The metadata I was rather hoping for would be things like number of channels, word length, nominal sample rate, bit packing... You know the stuff you need to actually unpack the audio into PCM streams!

Real metadata is usually going to be separate, at least in schemes like SMPTE 2110 and friends, but being able to dig the audio out of the packets using just the information in the multicast flow would have been nice (That is the bit the audio rate doings care about, the other stuff is for a higher level control system to sweat).

I also wonder how well SAP will really scale in a playout facility potentially having thousands of sources.

Regards, Dan.

[coppice]

That can be a pain with RTP. It is important for the two parties to negotiate their common capabilities up front, which SDP sort of does on a good day. However, you do need the ability to switch between formats on the fly, and RTP has issues that force you into inferring, rather than explicitly knowing, what is going on when that happens.

[mrpackethead]

Very early days for me. Still learnign all the ins/outs of it. 

I'm familar and use DANTE, which works well, but I really dont' like the lock in Audinte who have it locked up in a propriatory way.      AES67 is becomign more supported on pro audio, like Allan Heath and Yamaha, as well as other bits and pices.

Probaby am lookng at the full 'Fat' variant.

[Denis_K]

I tried to make sketches of audio transmission on aes67, it is eq Axia Livewire.
I managed to generate a UDP packet containing a PCM stream from the FPGA over the network to my computer, and it worked very well, consistently, and high quality. I could listen to my audio stream on several computers on the network at once. Since that time, I abandoned this project, but I would also like to find a way to implement the AES67 “receiver” inside the FPGA.

[Denis_K]

I'm familar and use DANTE, which works well, but I really dont' like the lock in Audinte who have it locked up in a propriatory way.

How about reverse engineering Dante by debugging its virtual sound card driver and by analyzing Ethernet packets?

Maybe it help to you https://github.com/kylophone/a-look-at-livewire