On Sun, 28 Sep 2014, Adrian Knoth wrote: So basically it just gives them total control of that eth port. the third party may not mind, but the protocol is still licensable meaning that the Linux user still would owe Audinate a fee to install the open source driver. I don't have a big problem with that... but I would have a problem being held responsible for all Linux users paying or not. In other words, I would like not to be in the money chain at all. My opinion is that Audinate should just accept that Linux is a major part of the ecosystem and provide the linux driver at the same fee as the others. I would like to think that the Linux community is trustworthy enough to be willing to pay for as many licenses as needed even with a source bundle. (a windows user could download one file and install 5 just as easy) Better (IMO) would be the RedNet box being open and loading a linux OS on it. That would open up a lot more possibilities. In fact I could say that about almost any hardware. But then life would be a dream. -- Len Ovens www.ovenwerks.net

On Sun, 28 Sep 2014, Fons Adriaensen wrote: Yes. Though what I have right now would not make it make sense. What I want to do woth it down the road would. Yup, that is why. Network transport is best with what you already have. The only reason for a jack back end of this sort is to use ethernet as an audio card/interface. But in the case where the master is the only audio IF for a DAW it starts to make sense again. Yes I could see that. -- Len Ovens www.ovenwerks.net

On Sun, 28 Sep 2014, Reuben Martin wrote: Any one system should only have to deal with 128 channels though, and the system eth port still has to see just as much traffic because it is (supposed to be) plugged into the same network stream (switch). I guess the switch should cut out some of the noise. I think the 192k is just in case Neil Young happens by, the studio can nod and go "Yup, we do 192k here." (yup is the Canadian version of yep :) Maybe I have things mixed up, but it seems from what I have read that AES67 is more of a wrapper or packaging for whatever other protocol is inside rather than an actual protcol of it's own. I found it very confusing as to what it actually is. This quote from one of the parties involved says this: "“The wider industry is likely most interested in where these do not overlap and how that will affect combined systems. AES67 is not intended to be a complete media distribution standard in the way that AVB is for Layer 2, but more an interoperability standard between proprietary solutions.” (from http://www.infocomm.org/cps/rde/xchg/SID-EE670EE5-035C3A9F/infocomm/hs.xsl/… ) I had a hard time thinking about what Audinate would have to gain by using an open standard, as it looks to me that they exist only to collect licence fees for Dante. A bit farther down in the same document we find: "One especially sensitive area of non-overlap among existing systems is device discovery" “It’s at that point that interoperability collapses, and that’s a pretty basic level,” says Shuttleworth, who attributes a lack of a compromise on device discovery among manufacturers to some combination of commercial-interest assertiveness and a preference for one’s own technology platforms. “Unfortunately, it’s a significant weakness in AES67, because choosing one network over another is a big investment decision for pro-audio equipment manufacturers. It remains to seen how discovery sorts itself out.” However, having pointed all that out, It does look like there is enough in common: -------------------------------8<-------------------------------- To achieve a sound interoperability definition, AES67 addresses these functional areas: Synchronization, which defines the mechanism for a common clock system Media clocks, which defines what media clocks must be supported and how they’re related to the common clock system Transport, which describes how media data is transported across the network Encoding and streaming, which describes the means by which audio is digitized and formatted into a the sequence of packets that constitutes a stream Stream description, which is required for connection management and specifies relevant stream information, such as network addressing, encoding format and origination information Connection management, which are the procedures and protocols used to establish a media stream connection between a sender and one or more receivers ----------------------------*<----------------------------------- For a Linux audio driver to be written that would access a RedNet audio IF (for example) well enough to use it as a DAW's only AI. It may mean using networking tools for sniffing out MACs, or the licenced win driver in wine to set it up originally. But once set up, any number of interfaces should be able to be used in sync. In a home studio setup, it should be possible to get away with no expensive switch hw.... A second NIC would be cheaper. I think there are not many who are looking for even 32 channels... and those who are would already be spending enough that licenced interfacing would not be a big deal. I am thinking that it is not just the amopunt of money one has to spend, but the bussiness models that play with more money are not so open source insistant either. (there are exceptions and changes yes) -- Len Ovens www.ovenwerks.net

On 09/29/2014 05:37 PM, Paul Davis wrote: SO SAY WE ALL!!!!!