Re: [LAD] Audio over net - an observation

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

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Sep 30 04:15:02 2014