On Sat, 15 Jul 2017, Bearcat Şándor wrote: It is not word clock. but wall clock with high accuracy so word clock can be derived. It is possible to do an end point without by treating packets in the same way as as buffer in an audio card where alsa does not have to be aware of the exact clock rise or fall to deal with it. However, If you wish to send audio from an internal audio card to any aes67 endpoint. Your computer must be able to be provide an ntp server with good enough accuracy to provide wordclock to both your internal audio ai and to act as a master clock on the network... or be able to sync your internal audio card to an external ntp server. This accuracy pretty much requires a HW ntp server. As I said the intel i210 ethernet cards at $60-ish seems to be about the cheapest route. Depending on how synced you want things... SRC can do a very good job and the broadcast industry uses it a lot. The zita-njbridge does a great job of connecting two computers together and I suspect using the zita src library as part of an aes67 driver would make <whatever> ethernet card workable so long as the computer was never expected to be a master clock. So an aes67 network with only two linux computers may not be usable or at least your network would not be wholely aes67 compliant. An endpoint with no ntp able to follow a masterclock closely doesn't seem fully compliant to me from what I have read. So the windows drivers downloadable from various places would have the same problem of not being fully compliant too. Some of the MacOS hw does have an ethernet chip with builtin ntp server. So a driver that does what the windows driver does should be possible. -- Len Ovens www.ovenwerks.net

On Sun, 16 Jul 2017, Hanspeter Portner wrote: Thats what I get for answering off the top of my head from a camp site :P I am not aware of anyone managing to get sw mode to be accurate enough to derive wordclock from. -- Len Ovens www.ovenwerks.net

On Thu, 20 Jul 2017, Bearcat Şándor wrote: ... url omitted The big thing here is prioritize. The switch has to have more than one transmit/receive queue to be able to do this. You may be able to do that with your main NIC, but the advantage of using a second $50 i210 is that it has a hw PTP clock built in. So far as I know, it is very difficult to get a sw ptp clock to have the stability needed. However, if you used a computer for nothing else but ptp and net forwarding you might do it... I just think a $50 NIC is cheaper. That depends on the AES67 driver. If it is built to talk to jack dirrectly, then jack is quite important. If the driver is ALSA... not so much. Maybe, the cpu inside really does matter for a sw ptp clock. Latency has to be much better than for audio alone. Alsa deals with 32 samples at a time or much more (128 is much more common). but to have stable audio, ptp has to be more accurate than 1 sample. This would be time for a real time kernel for sure. Priorities would have to be right on... and maybe multi-cores would not be the best thing. (no hyperthreading for sure). One place to look at real time latency is: https://www.osadl.org/Hardware-overview.qa-farm-hardware.0.html Where they have many combinations of HW running in real time testing latency. often slower cpus have better latency tests than faster or higher core count machines. If your mini computer with 4 or more NICS will cost more than about $400, maybe this would be better: https://www.sweetwater.com/store/detail/AVBSwitch I have been surprised at total cost of putting a small system together even assuming some parts I already have laying around (case, PS, KB, mouse, display) The best thing is do your homework, find the list of ethernet protocols aes67 expects and see if there are more reasonably priced switches that will give you enough assuming your NIC can provide a network ptp clock. The big thing with aes67 is A) paying for the protocol spec. (thankyou aes) and B) doing the dev work... that is putting it all together. AES67 does not have any discovery built in, but because your speakers use bonjour, I would work with that (linux has Avahi that covers most of this). I am not sure how AES "you must pay for the protocol" would go with a GPL project because open source effectively gives the protocol away for free. AVB on the otherhand, hosts a github project that is open source. If it was me (and I am not a great example :) I would go aes67 direct to jack backend. That is mostly because I am familiar with the jack api and when I looked at trying to do the same thing in alsa, it seemed confusing and more complex but that is just my personal POV. I am sure once I have made my first alsa connection my POV will change. Because the ethernet code is system and not user (in particular setting up queues and priorities), alsa may make more sense. Having said all that, balanced xlr audio cables are a lot cheaper than AoIP-anything. (even ones you have to make yourself) Your speakers support balanced audio in. -- Len Ovens www.ovenwerks.net