Re: [LAD] Anyone working on software implementation of Ravenna for Linux?

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