| Electronics > Projects, Designs, and Technical Stuff |
| AES67 Implementaitons on FGPA or Microcprocessor |
| (1/2) > >> |
| 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. |
| Navigation |
| Message Index |
| Next page |