Re: [LAD] AoIP question

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" <len@email-addr-hidden> 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
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sat Oct 11 16:15:02 2014