<p dir="ltr">I know OSX supports these AVB interfaces and switches over gigabit Ethernet, any Linux solutions?</p>
<p dir="ltr"><a href="http://www.motu.com/products/avb/avb-switch">http://www.motu.com/products/avb/avb-switch</a><br>
<a href="http://www.motu.com/products/avb/1248">http://www.motu.com/products/avb/1248</a></p>
<div class="gmail_quote">On Oct 10, 2014 7:33 PM, "Len Ovens" <<a href="mailto:len@ovenwerks.net">len@ovenwerks.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 10 Oct 2014, Winfried Ritsch wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am Sonntag, 5. Oktober 2014, 08:47:25 schrieb Len Ovens:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have been doing some reading on audio over IP (or networking of any<br>
kind) and one of the things that comes up from time to time is collisions.<br>
Anything I read about ethernet talks about collisions and how to deal with<br>
them. When I was thinking of a point to point layer two setup, my first<br>
thought was there should be no collisions. Having read all the AES67 and<br>
other layer 3 protocols there does not seem to be mention of collisions<br>
really. My thought is that on a modern wired network there should be no<br>
collisions at all. The closest thing would be a delay at a switch while it<br>
transmitted another packet that in a hub would have been a collision.<br>
<br>
So my thought is that AoIP at low latencies depends on a local net with no<br>
collision possible. Am I making sense? or am I missing something?<br>
<br>
</blockquote>
just to add my two cents for ideas:<br>
<br>
In robotic there is a open source solution for linux kernels called rtnet,<br>
which has exactly the purpose to prevent collision and garantee low latency<br>
over network:<br>
<br>
<a href="http://www.rtnet.org/" target="_blank">http://www.rtnet.org/</a><br>
</blockquote>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think using rtnet would be nice for a open source simple audio-card over<br>
Ethernet.<br>
</blockquote>
<br>
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:<br>
- 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.<br>
- 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?<br>
- 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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:<br>
- a PCIe interface that looks like an audio card but connects to AoIP boxes. (AudioScience has one, with Linux driver, for Axia AoIP Livewire)<br>
- A native Linux AES67 driver.<br>
<br>
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.<br>
<br>
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.<br>
( <a href="http://www.axiaaudio.com/ravenna" target="_blank">http://www.axiaaudio.com/<u></u>ravenna</a> )<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<br>
--<br>
Len Ovens<br>
<a href="http://www.ovenwerks.net" target="_blank">www.ovenwerks.net</a><br>
<br>
______________________________<u></u>_________________<br>
Linux-audio-dev mailing list<br>
<a href="mailto:Linux-audio-dev@lists.linuxaudio.org" target="_blank">Linux-audio-dev@lists.<u></u>linuxaudio.org</a><br>
<a href="http://lists.linuxaudio.org/listinfo/linux-audio-dev" target="_blank">http://lists.linuxaudio.org/<u></u>listinfo/linux-audio-dev</a><br>
</blockquote></div>