12 Sep
2014
12 Sep
'14
12:52 a.m.
On Fri, 12 Sep 2014, Arnold Krille wrote:
Yes. I have included midi links in real time as it happens as part of the
audio packet. network data has other uses and that was why I wanted both.
On Thu, 11 Sep 2014 14:24:56 -0700 (PDT) Len Ovens
<len(a)ovenwerks.net>
wrote:
Shouldn't be, The network traffic does not need to be real time, but the
network does. In other words the way the host computer deals with network
traffic does not need to be real time. The computer puts a packet into a
buffer, this part does not need to be real time. The network sends it
while there is no audio traffic, this part does need to be real time.
Where I see your info as being useful though, is
if I choose to send
data (which could be varying sized packets) I may still wish to set
the data packet size to a fixed size depending on what is left from
audio. The whole network end of things needs to be decoupled from
real time.
That last sentence is a bit contradicting. You want to send audio over
network, you want the audio to be near realtime. But you want to
decouple network from realtime... (In math: A==B && B==C && A!=C) To be honest,
I have spent a lot less time thinking about the network
traffic part of things than the audio part of things. The reason for
this is that the use cases for allowing network through our line is
small. As has already been commented, a desktop can have a second NIC
and the laptop generally has wireless. The main usecase for network
through the same IF might be radio work where one might have a SIP
connection (phone line) going through net. (anyone see others?)
Because the AI has a second NIC and an OS, it should be possible to
set up the SIP session on that box.
There is a widespread use-case for audio and non-audio network traffic
on the same segment: audio and control/midi messages on the same
segment. And you don't want your fader moves to interrupt your audio. And your current thinking seems to be about using a
dedicated
network-link between PC and audio-interface with a possible chain-link
to other interfaces. But what about a dedicated network (with switch)
to connect multiple PCs and audio-interfaces? Then you have to deal
with lots more channels, thus lots more realtime data and also lots
more control-messages.
Why? there is already stuff out there that does that (with higher latency
of course) The main idea is still to replace a FW audio interface up to
around 32 channels, not provide a generic network audio protocol.
PS: Maybe this question sound foolish: Why not AVB /
open AVB?
What is the latency? Or what is the minimum latency I could get on a link
with say 50% audio/network traffic and a 100m link? The real show stopper
though is that the end points require dedicated HW. That is it would not
just work with the average laptop or desktop NIC. AT least with the
desktop a new NIC could be added. The question as to the NIC driver
actually using the required capability is something else.
--
Len Ovens
www.ovenwerks.net