28 Sep
2014
28 Sep
'14
5:52 p.m.
Focusrite's RedNet series of interfaces uses Dante as the transport
protocol. Going to the Dante home page I find that an audio driver
(mac/win) is available for $30 or so (there is apparently a linux version
available from another party). Yet Focusrite sells a RedNet PCIe
card for around $800... one hopes it has more on it than an ethernet port
:) That looks like a sound card to the computer. This card does not look
like it has a special plug on it (like the locking ones some of the
snake/mixing boxes have). I am wondering what other processing might be
happening on this card to make it worth Focusrite's effort to produce.
Routing to be sure, but the Interface boxes all have that anyway. DSP?
Effects? maybe, but not useful on a Linux box I am sure.
I realize a big part of the cost is scale (lack of scale in this case),
but can't help but think that the money would be better spent on a better
mother board. For example moving from an i5/7 to a Xeon based board.
Reading more about the RedNet PCIe card. It is 4 lane, but the recomend
installing in an 8 lane slot. They also recomend using a GB switch to
which both the PCIe audio card as well as the MB native Ethernet port is
connected. They are suggesting that all the audio will go through PCIe AI
card and that control will go through the native enet port. This all may
be to do with 128 channels at 192khz at 3ms. The native enet port has the
dante driver on it too.
I am not suggesting that the Linux world embrace Dante as a protocol so
much as learning from its implementation. I am not sure that building for
192k is the way to go though.
Some numbers... if they are talking 192k with a 32sample buffer (like jack
with 16/2?) it would seem there is a lot of extra latency built in as at
48k and 16/2 the raw latency from card to jack is only .6ms and at 192k it
would be less than .2ms... .3ish for return trip. So the network and ADC
together take a lot longer. Considering my USB IF at 48k has an ADC time
of ~.5ms, most of that is network.
I am looking forward to testing Fons' n2jbridge jack backend. I will not
be using 192k however. I generally use 48k, but may try 96k to test
differences in latency. My own low level protocol is way down the road, if
it ever happens.
--
Len Ovens
www.ovenwerks.net
28 Sep
28 Sep
6:11 p.m.
On Sun, 28 Sep 2014, Len Ovens wrote:
Focusrite's RedNet series of interfaces uses Dante
as the transport protocol.
Going to the Dante home page I find that an audio driver (mac/win) is
available for $30 or so (there is apparently a linux version available from
another party). Yet Focusrite sells a RedNet PCIe card for around $800... one
hopes it has more on it than an ethernet port :) That looks like a sound
card to the computer. This card does not look like it has a special plug on
it (like the locking ones some of the snake/mixing boxes have). I am
wondering what other processing might be happening on this card to make it
worth Focusrite's effort to produce. Routing to be sure, but the Interface
boxes all have that anyway. DSP? Effects? maybe, but not useful on a Linux
box I am sure.
No effects at all just routing.
--
Len Ovens
www.ovenwerks.net
6:12 p.m.
On Sun, Sep 28, 2014 at 08:52:10AM -0700, Len Ovens wrote:
version available from another party). Yet Focusrite
sells a RedNet
PCIe card for around $800... one hopes it has more on it than an
ethernet port :) That looks like a sound card to the computer. This
Actually, it does not. It's a glorified DMA buffer attached to a
PTP-capable NIC/MAC.
Chances are it's somewhat flexible wrt layer-2 protocols, but other than
that, it's really just a media converter with a clock.
You can have all this for way less money these days, but back then, if
you were a theatre or an opera with a multi-million budget, you wouldn't
care about $800 for the playback engine.
I've seen Ardour outputting to this card, and I've briefly discussed
open-sourcing the driver at Frankfurt musikmesse in 2012. The 3rd party
vendor wasn't particularly reluctant, so if you want to give it a try,
feel free to reach out to them.
Cheers
--
mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
11 p.m.
On Sun, 28 Sep 2014, Adrian Knoth wrote:
On Sun, Sep 28, 2014 at 08:52:10AM -0700, Len Ovens
wrote:
So basically it just gives them total control of that eth port.
version available from another party). Yet
Focusrite sells a RedNet
PCIe card for around $800... one hopes it has more on it than an
ethernet port :) That looks like a sound card to the computer. This
Actually, it does not. It's a glorified DMA buffer attached to a
PTP-capable NIC/MAC. I've seen Ardour outputting to this card, and
I've briefly discussed
open-sourcing the driver at Frankfurt musikmesse in 2012. The 3rd party
vendor wasn't particularly reluctant, so if you want to give it a try,
feel free to reach out to them.
the third party may not mind, but the protocol is still licensable meaning
that the Linux user still would owe Audinate a fee to install the open
source driver. I don't have a big problem with that... but I would have a
problem being held responsible for all Linux users paying or not. In other
words, I would like not to be in the money chain at all.
My opinion is that Audinate should just accept that Linux is a major part
of the ecosystem and provide the linux driver at the same fee as the
others. I would like to think that the Linux community is trustworthy
enough to be willing to pay for as many licenses as needed even with a
source bundle. (a windows user could download one file and install 5 just
as easy)
Better (IMO) would be the RedNet box being open and loading a linux OS on
it. That would open up a lot more possibilities. In fact I could say that
about almost any hardware.
But then life would be a dream.
--
Len Ovens
www.ovenwerks.net
11:17 p.m.
On Sun, Sep 28, 2014 at 08:52:10AM -0700, Len Ovens wrote:
I am looking forward to testing Fons' n2jbridge
jack backend.
But do you have anything to connect it to ?
A backend using the njbridge format makes sense only when
connected to some hardware audio interface (analog or digital),
or to emulate netjack.
The latter means a master/slave relationship, which is exactly
what the whole njbridge design wants to avoid (two reasons for
that being that 1. it doesn't scale and 2. it's fragile (if the
master has a problem the slaves will fail as well).
What would make sense is an option in the njbridge receiver
that would make it assume (and check) that the sample clock
is synced to the one of the backend, and bypass resampling.
All the rest of the logic would stay in place, to ensure
a defined latency regardless of how the periods on backend
and transmitter are aligned (they could even be different).
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
29 Sep
29 Sep
2:35 a.m.
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. 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 am not suggesting that the Linux world embrace Dante
as a protocol so
much as learning from its implementation.
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.
-Reuben
4:22 a.m.
On Sun, 28 Sep 2014, Fons Adriaensen wrote:
On Sun, Sep 28, 2014 at 08:52:10AM -0700, Len Ovens
wrote:
Yes. Though what I have right now would not make it make sense. What I
want to do woth it down the road would.
I am looking forward to testing Fons'
n2jbridge jack backend.
But do you have anything to connect it to ?
A backend using the njbridge format makes sense only when
connected to some hardware audio interface (analog or digital),
Yup, that is why. Network transport is best with what you already have.
The only reason for a jack back end of this sort is to use ethernet as an
audio card/interface.
or to emulate netjack.
The latter means a master/slave relationship, which is exactly
what the whole njbridge design wants to avoid (two reasons for
that being that 1. it doesn't scale and 2. it's fragile (if the
master has a problem the slaves will fail as well).
But in the case where the master is the only audio IF for a DAW it starts
to make sense again.
All the rest of the logic would stay in place, to
ensure
a defined latency regardless of how the periods on backend
and transmitter are aligned (they could even be different).
Yes I could see that.
--
Len Ovens
www.ovenwerks.net
11:24 p.m.
On Sun, 28 Sep 2014, Reuben Martin wrote:
On Sunday, September 28, 2014 08:52:10 AM Len Ovens
wrote:
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.
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. 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/…
)
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
11:37 p.m.
On Mon, Sep 29, 2014 at 5:24 PM, Len Ovens <len(a)ovenwerks.net> wrote:
“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.”
welcome to what killed mLAN. transport specs adopted as a standard,
discovery remained proprietary and single-vendor only, more or less.
"all of this has happened before and all of it will happen again"
30 Sep
30 Sep
12:10 a.m.
On 09/29/2014 05:37 PM, Paul Davis wrote:
On Mon, Sep 29, 2014 at 5:24 PM, Len Ovens <len(a)ovenwerks.net
<mailto:len@ovenwerks.net>> wrote:
“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.”
welcome to what killed mLAN. transport specs adopted as a standard,
discovery remained proprietary and single-vendor only, more or less.
"all of this has happened before and all of it will happen again"
SO SAY WE ALL!!!!!
3729
days inactive
3730
days old
linux-audio-dev@lists.linuxaudio.org
9 comments
6 participants
participants (6)
-
Adrian Knoth -
Fons Adriaensen -
Len Ovens -
Paul Davis -
Reuben Martin -
Ricardus Vincente