[LAD] AoIP question

Len Ovens len at ovenwerks.net
Sat Oct 11 02:33:26 UTC 2014


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



More information about the Linux-audio-dev mailing list