5 ms·

Very nice! Can you link some resources regarding how to implement AES67? What kind of latencies are you able to achieve?

• rectang 5y ago
  FWIW, there's a resources page with a number of links that match your inquiry: https://aes67.app/resources https://aes67.app/resources Unfortunately the standard itself you have to buy. It's 50 USD for non-AES-members. https://www.aes.org/publications/standards/ https://www.aes.org/publications/standards/
  • phlhar 5y ago
    A draft of the standard that is as far as I know pretty much complete can be found online on the AES website: https://www.aes.org/standards/comments/drafts/aes67-r-171107-draft-rev-cfc.pdf https://www.aes.org/standards/comments/drafts/aes67-r-171107...
  • frabert 5y ago
    Yes, that's the reason I was asking :( A number of projects implement it, but I'm not an AES member and didn't feel like spending the 50USD for the official specs. I was hoping someone had made a writeup of the overall protocol.
    • kierank 5y ago
      RTP PCM packets timed to a Precision Time Protocol clock. As most (all?) PC audio devices don't support clock drifting the audio clock to the PTP clock, this application will either resample fractionally or click now and then. So not AES67 in the true sense.
      • frabert 5y ago
        Ahh that answers one of the questions I had when I was thinking about implementing something like this myself, in that none of the audio APIs I know of (WASAPI and ASIO) would give you any chance of syncing your clock with external sources, thus leaving you at the mercy of clicks. Thanks for clearing that up!