<div dir="ltr">For what gives, and perhaps even not useful for this and more for AVB, but ordered two I210T1 each $44 from Amazon just for testing peer to peer. My plan is still a Rednet 3 as I see it the only option for Linux now to create a multi-channel network for the studio with the current ADAT's DAC/ADCs's on hand. (Don't see Thunderbolt happening to become mainstream on Windows and for Linux perhaps it will never happen) I am not sure what AES67 FR implemented in the Red-net 3 firmware (Bonjour or any other discovery protocol). Still learning and reading lots of AE67 material and you-tube got some good video's as well. </div><div class="gmail_extra"> <div class="gmail_quote">On Sat, Oct 21, 2017 at 10:13 PM, Chris Caudle <<a href="mailto:chris@chriscaudle.org" target="_blank">chris@chriscaudle.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, October 2, 2017 5:12 am, Philippe Bekaert wrote: > I’m also in contact with people at > Merging regarding their VSC driver in progress for Linux. Did you get a copy of the ALSA driver? The current git head does not compile, I waited to see if merging would correct that on their own, but still not corrected after a month, so I need to ask what is happening there. Not encouraging that it is actually getting any attention if the source can go more than a month in a non-buildable state. > I'm aiming for a jack client application, and perhaps a jack audio driver > (like the net drivers). The latter allow to have jack running at AES67 > clock, and being fully transparent (no sample rate conversion). But the > former, a client application, is probably better if you just want to > receive and monitor / send AES67 on / from a computer having a sound card > already. I recommend a jack audio driver. If you want to monitor from a local sound card you can always load zita-j2a and zita-a2j resampling bridges, that work has been done so no need to implement twice what Fons has already implemented. The advantages of a net driver is that you can in principle collect streams from different devices that are in the same clock domain and have a large virtual sound card. For example, in a home recording environment you could have a Ravenna output device in your room with a computer, have a Ravenna in/out device in a different room with someone playing keyboards, and a Ravenna in/out device in the house large room playing guitar, and all three of those physically separated devices could be treated as one large audio interface. I am not sure if jackd will let a driver load and then change the number of ports at a later time, so how configuration would work is a task that needs to be investigated early (e.g. would you have to discover and configure Ravenna streams first, then load the net driver, or could the net driver be loaded with some arbitrary number of ports declared to jackd, and various Ravenna streams connected and disconnected from those declared ports at run time). I am still struggling to find reasonable cost network connected interfaces. The small device from Hasseb I linked last time is reasonable cost, but very low feature, I would prefer at least a duplex stereo device. Focusrite have a new two channel Dante device which could run in AES67 mode, but it is output only, and I think is around US$400. The 4 input 2 output Cymatic device is still not available yet, and even though the 24 channel Cymatic device has reduced price by 50% lately, that is the base USB version only, so by the time you purchase the Ravenna option card it is still around US$1000. Not a bad price for 24 channels, but still could be considered quite a lot to spend on a hobby investigation project. If a Windows computer is available, the Lawo R3lay virtual sound card for Windows is the best option to get started. I tried it and was able to send audio between two Windows laptops. You will need a PTP master on the network, that VSC will not act as clock master, but I am running a BeagleBone Black as PTP master (uses chronyd to sync time to ntp, then provides the ntp time to the network using linuxptp). You could also use your existing linux machine to act at PTP master, it would just have more jitter in the PTP performance if you do not have hardware timestamping capability (the BeagleBone has hardware timestamp in the MAC layer but not the phy, not ideal but still fairly high performance). -- Chris Caudle <div class="HOEnZb"><div class="h5"> _______________________________________________ Jack-Devel mailing list <a href="mailto:Jack-Devel@lists.jackaudio.org">Jack-Devel@lists.jackaudio.org</a> <a href="http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org" rel="noreferrer" target="_blank">http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org</a> </div></div></blockquote></div> </div>