[Jack-Devel] AES67 / SMPTE ST 2110-30

[happy musicmaker]

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.


On Sat, Oct 21, 2017 at 10:13 PM, Chris Caudle <chris at chriscaudle.org>
wrote:

> 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
>
>
> _______________________________________________
> Jack-Devel mailing list
> Jack-Devel at lists.jackaudio.org
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/jackaudio/attachments/20171023/e8ebb884/attachment.html>