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.
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.
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!
Comments
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.
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.
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!