On Mon, October 23, 2017 11:53 am, Philippe Bekaert wrote: Correct, I have not looked up the Audinate patent(s) yet, I do not know what was unique enough to award a patent. In any case ALC Networx did not seem to think that the Ravenna approach of using PTPv2 (IEEE 1588-2008) for synchronization and RTP/RTCP (IEEE 1733-2011 and IETF RFC3550 and RFC3650) for media streams would be covered by any patents. Yes, time stamp calculations and latency adjustments seemed like the only part that would possibly be a little tricky. The rest seems like just manipulating sample values to get into the correct order in the packet. Jack uses floating point for sample format and RTP uses integers, so the usual conversion between integer and floating point that you would do for sending samples to a hardware sound card applies. OK, the first time I misread that as an ASIO library, i.e. the Steinberg designed Windows specific multi-channel audio specification, not asio C++ library for asynchronous I/O. I checked my fedora installation and that is easily available as the asio-devel package. I think libasio-dev is the equivalent in debian. Seems that should not be a problem for any recent distribution. Actually, now that I look at the details that seems to be just headers, I'm not sure where the actual libraries are implemented. Something to investigate later. One thing I do not know is what the clock will be set to using one of the standalone audio devices as the PTP master. I'm not sure if those devices have a battery backed clock, so potentially if you set your system clock to the PTP clock in a network which only contains a Ravenna device for example, your system clock could jump to some unexpected value, potentially far in the past. Just something to consider for documentation purposes for the moment, hopefully I will find a way to get access to some hardware for testing. That is always the case, whether using network audio, USB, or AES/EBU or S/PDIF connections, so again I think just a note for the documentation. Typically any devices which are on the same network segment or VLAN will end up using the same master clock because of the PTP best master clock algorithm so in practical installations should not be a problem. I think you would have to specifically change the default clock domain from clock 0 to some other value to have that problem. A second level of consideration is that two devices which are using the same master clock could still be configured to use different sample rates, so those two devices could still not be used together as a single aggregate audio device. That could be manually checked at the beginning, but eventually should be part of whatever configuration method exists, compatibility of stream parameters should be verified before those streams are allowed to be configured together as part of the aggregate device. -- Chris Caudle