I know OSX supports these AVB interfaces and switches over gigabit Ethernet, any Linux solutions?
http://www.motu.com/products/avb/avb-switch http://www.motu.com/products/avb/1248 On Oct 10, 2014 7:33 PM, "Len Ovens" <[email protected]> wrote: > On Fri, 10 Oct 2014, Winfried Ritsch wrote: > > Am Sonntag, 5. Oktober 2014, 08:47:25 schrieb Len Ovens: >> >>> I have been doing some reading on audio over IP (or networking of any >>> kind) and one of the things that comes up from time to time is >>> collisions. >>> Anything I read about ethernet talks about collisions and how to deal >>> with >>> them. When I was thinking of a point to point layer two setup, my first >>> thought was there should be no collisions. Having read all the AES67 and >>> other layer 3 protocols there does not seem to be mention of collisions >>> really. My thought is that on a modern wired network there should be no >>> collisions at all. The closest thing would be a delay at a switch while >>> it >>> transmitted another packet that in a hub would have been a collision. >>> >>> So my thought is that AoIP at low latencies depends on a local net with >>> no >>> collision possible. Am I making sense? or am I missing something? >>> >>> just to add my two cents for ideas: >> >> In robotic there is a open source solution for linux kernels called rtnet, >> which has exactly the purpose to prevent collision and garantee low >> latency >> over network: >> >> http://www.rtnet.org/ >> > > This looks like the same idea I had in the begining. I may look farther > when I have time. Prioritizing audio (RT) through the net and tunnelling > the low priority packets through. It is nice to know I don't have to do all > the work and there is already something like this out there. > > > However, with todays NICs and switches, It would seem to me there really > should be no collisions anyway. In order for there to be collisions, more > than one nic needs to be feeding the same wire as in the days of 10M coax > or with a hub. (I am not talking about wireless networks which do have > collisions because they are all effectively on one wire or limited number > of channels and have to deal with other interference as well.) With duplex > NICs (all of them since before 100m) there are two lines for each NIC, tx > and rx. The switch is a cpu with a number of NICs, each of which is duplex. > The packet comes in, gets queued and then resent. Unless my understanding > of switches is off base, I don't see room for collisions at all. > > I think using rtnet would be nice for a open source simple audio-card over >> Ethernet. >> > > It could be used in a more complex way as well... the point in all this > was originally... That there are getting to be less audio IFs that Linux > can use outside of USB ones because firewire interfaces are becoming rare. > This becomes a problem for those using a laptop where there is no longer a > slot to add an after market FW IF. USB AIs have some problems: > - Drivers. The USB3 drivers seem to giving people with USB2 AIs trouble > with some HW. A USB AI that works for one kernel version may stop working > with it the next. > - Clean USB ports. Finding a clean USB port that is not hubbed with some > other inside the box device can be difficult. Generally there is only one > port on any laptop that is clean and on it's own interrupt... where to plug > the midi devcie? > - While the i/os work to standard, USB audio devices often use > non-standard interfaces for other functions like routing, mixing and other > DSP kinds of things. > > So USB is out, FW is out... what is left as an interface all laptops (and > desktops) have? Network seems to be it. Despite comments I have made about > laptop makers perhaps opting only to provide wireless network, one of the > real pluses for wired network is that it is much harder to listen to by > unauthorized people and so it is likey to stick around. It is fast enough > and generally has it's own IRQ. SO the idea of making an open audio IF > using the NIC. > > Looking at other open HW projects, the cost is higher to DIY. Looking at > the MOD DUO (which is funded BTW) it looks about 3 to 4 times as much as > the Zoom box that does (to the guitarists eyes) the same thing. So looking > at a good quality USB stereo IF at $100 to $150 and change that to $400 or > more to build it yourself. There are already s/pdif IFs that are DIY. > Generally they are either input or output. I do not get the idea they are > cheap though. > > So while the idea of an open audio IF is a great idea still. It is not the > answer for the small studio running open source SW looking for a Linux > compatible AI. At least not short term. > > What does seem to be emerging are AoIP interfaces. They are not as cheap > as some of the USB2 devices, but if they are reliable and the routing and > mixing can be controled from Linux, This would be a good path forward. The > only two PCIe audio IFs I know of that claim to have working Linux drivers > are the RME (sort of) and the AudioScience cards (which use two drivers, > ALSA for audio and another for DSP control). Both of them are ~$1k > solutions for 8channels or so. The AoIP devices seem similar. This is where > AES67 comes in. It looks like the near future will see most AoIP boxes > support AES67. There are two ways to deal with these boxes: > - a PCIe interface that looks like an audio card but connects to AoIP > boxes. (AudioScience has one, with Linux driver, for Axia AoIP Livewire) > - A native Linux AES67 driver. > > Both methods have uses. A native Linux driver will be a cost effective way > to add an AoIP IF or two as an AI to a DAW. If I had an AoIP box that > supported AES67, that would be where I would put my time. For a bigger > setup where more than one computer may be involved or a high number of > tracks, the PCIe card would probably be better. > > Livewire BTW, is now compatible with Ravenna, which claims to already work > with AES67. New LiveWire products are fully Ravenna compliant. (new designs > such as the xnode audio IF) The axia site seems to indicate that compatable > means works with 24bits/48k/48samples/packet. Compliant means all Ravenna > streams work. Axia says Livewire version 2.0 is Ravenna. > ( http://www.axiaaudio.com/ravenna ) > > AES67 (Ravenna and Livewire too) is more broadcast oriented than recording > studio. I don't know if anyone would care to comment on the quality of > broadcast audio compared to recording studio. What I do see in broadcast is > much more willingness to be open about what is inside and more support for > Linux than in the "made for Mac" DAW community. > > There is still a place in Linux for "use what ya have". Those who wish to > buy an AI for their Linux project may wish to buy something that is known > to work. AoIP could be in that place with an AES67 linux driver. > > > > -- > Len Ovens > www.ovenwerks.net > > _______________________________________________ > Linux-audio-dev mailing list > [email protected] > http://lists.linuxaudio.org/listinfo/linux-audio-dev >
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
