[LAD] Audio over net - an observation

Len Ovens len at ovenwerks.net
Mon Sep 29 21:24:10 UTC 2014


On Sun, 28 Sep 2014, Reuben Martin wrote:

> On Sunday, September 28, 2014 08:52:10 AM Len Ovens wrote:
>> Yet Focusrite sells a RedNet PCIe
>> card for around $800... one hopes it has more on it than an ethernet port
>
> A lot of the work is offloaded onto hardware rather than CPU, so it can provide
> more stability and deterministic latency. It also allows you to bypass the
> networking stack. When you have four 64 channel audio consoles on the same
> network using things such a multi-flows (dante can use multicast when a single
> source has more than one destination) the traffic can get quite intense and a
> hardwired dante card starts to make a lot of sense.

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.

> In live audio the 32 bit
> sample size is more important than the sample rate. 48k is plenty, and you can
> set latencies down to .2ms at that sampling rate on a dante network. Besides,
> sticking with 48k makes integration with broadcast folks a lot easier.

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  :)

> I think Linux world should keep an eye on the adoption of AES67. AVB is
> (almost) dead since there has been no serious commitment to it from the
> network switch manufactures. Audinate has committed to supporting it. I've
> already seen QSC demo their newest Q-SYS product line that supports AES67.
> Harman's BLU Link products are starting to support it. I don't think there is
> a single proprietary layer-3 audio transport that hasn't at least claimed they
> will support it.

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/38540.htm 
)

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


More information about the Linux-audio-dev mailing list