3 Sep
2014
3 Sep
'14
1:19 a.m.
On Wed, 3 Sep 2014, raf wrote:
i found this discussion very interesting, I have
thoughts for a similar system.
Len, I particularly enjoy reading your thoughts, they find a echo in my brain.
While looking for info, in the AES67 path there is the archwave system which has recently
integrated copperlan control in his chip.
http://archwave.net/
While this is proprietary solution, the chip (without knowing about hardware and licence
costs if any) could be used to design a AI with embedded ethernet, multi-channel audio,
usb recording...etc.
Then controlling the board via copperlan is available to majors OSes, linux not beaing
fully ready yet, but the SDK allows to create a jack client.
this may not be the path you want to follow.
As with some of the other similar protocols, I am interested in latency.
The site pointed to above has a "Details" tab which I followed, but the
details seem to be "We're great" more than some spec other than pointing
at other standards (AES67 and copperlan) However, the give away to me is
the "integrating with existing network". Low latency tends to fail at that
point.
The one thing I did come away with :) is that like everything else these
days, being able to control the interface via a web interface makes sense.
It is almost the expected method. The biggest down side to this is the
size of data needed to change one thing makes continuous control almost
impossible. But for set up it might just be ideal.
Copperlan looks similar to what I am suggesting, but is closed so far as I
can tell. That is, even though there may at some point be a linux driver,
it will not be packaged with most ISOs. Other people will not use it
because it is not open. If I look at where this thread started, it was
replacing one of the few good open bits of HW. There are new audio
interfaces around that will plug into PCIe slots, but not many of them
that have open anything, certainly not linux drivers. SO openness is
important. The particular device mentioned was a FW device that used to be
of interest to those using a laptop because it has been found that while
there are USB2 devices that do work with Linux because of class
compliance, they are finicky to get good performance out of. Some times a
kernel change can kill it.
A non-open driver for coppernet will have problems (look at some of the
graphics drivers) This one is already way late. To rely on a closed source
house one expects a linux driver the same day OSx/win drivers come out.
This will obviously not happen.
If I was going to use any existing project at all, it would be netjack.
Coming up with a level 2 variant would probably make it what I want.
--
Len Ovens
www.ovenwerks.net