[Ardour-Dev] Banking on a surface
Len Ovens
len at ovenwerks.net
Fri Jun 24 10:39:33 PDT 2016
On Fri, 24 Jun 2016, Melanie Bernkopf wrote:
> Yes bundles might bring in a bit of latency but I suspect that in the case of a
> bank change it would be OK or less than surface setting everything to zero and
> waiting for updates. Anyways a bit of latency is allways there and at work we
If I was to set up bundling, it would always be there, not just bank
change. (assuming no extra duplcate code) This is because, I would que
them and send on a timed basis... there may be a better way, but I am not
seeing it right now.
> once traced out the difference between 10M 100M 1G 10G networks an their latency
> it was quite surprising to see that they are in that way all the same. what makes
> a big difference is UDP and TCP the later being a bit slower ( but possible to
> bring to the same speed with deep kernel hacks). In the end well 10M is not up to
> date 100M is okay for a control Surface I think 1G being better but either
> expensive or using strange standards.
GB networks will use (in a linux net) 100m standards for packet size if
the network is set that way. One actually has to set up for over size
packets and then they are only local as the Inet runs at 1500 anyway. A
lot of systems come with GB on the board, even the small arm boards like
the odroid. The difference between single messages is that single messages
are (so far as I know) one to a packet. Bundles are a group of messages to
a packet. The bundle, netwise, will take less time/bandwidth to move as
each bundle has only one packet overhead to deal with. If the lib is smart
it would do this on its own. (check if there are more than one message in
the queue, send them all in one packet) Like wise, on receiving a bundle,
the lib should break it down into messages as far as the application is
concerned.
I am thinking that there are places I could bundle things. For example, if
the smae info is being sent to both a strip and a select/expand strip
(expand is a new concept I am working on) then bundle makes sense. Track
name, no of input, no of outputs and track comment are always sent
together... another bundle possibility. In these cases there would be a
latency reduction by using bundles as well as a network traffic reduction
and so worth while. This is down the road though as I have bigger "fish to
fry" right now.
> In the end I see two questions that would sum it up:
>
> What gives the least latency?
> What is the least work to implement?
>
> Second question is maybe more important because it is the same amount of data to
> be transfered which leaves the main source of latency to the Microcontroller in
> the surface and how fast it can handle things (again up to the surface designer
> ;) ).
Both are important. Tied to latency is net bandwidth, which is finite. The
next big change in audio is likely to be AoIP. Linux could be at the front
of all this and the reality is that there are Linux bits of code out
there, but no one is putting it together. AES67 has come but no one has
written open linux drivers for it... and for the most part this is a HW
thing... PCs do not come with a NIC that can do a good job of it. So
laptops can't use it... a Mac can by the way. AVB is here now too. Motu is
making nice AVB boxes that do work with a Mac (the new Macs come with AVB
built in). In the PC world these show up as a USB gateway to AVB :P But
this will change, and then using extra BW on the net is not a good thing.
The intel i210 NICs are not that expensive for a desktop so maybe we will
see something soonish.
> Long Text again but the conclusion would be if it is working allready leave it
> that way
Yes... and no. Improvements are always good :) I will leave the banking
layout as is (always fill) unless there is a large outcry for something
different.
> not confusing people. But you should also decide where to draw the line of what
> ardour is doing and what is better to be done on the surface or app. If banksize
> is set just send that amount of strips if not set send all and leave it to the
> other side to deal with it (sounds quite rude but that would be the line I would
> draw on that matter).
There are defaults:
- no feedback
- no bank
- available strips includes inputs, buses and VCAs
- master/monitor are separate
If the surface wants something different it has to tell Ardour about that
using /set_surface or /set_surface/*. It looks like there will also be
some preset profiles like maybe /ttc-2 for example which would just be
like sending /set_surface iiii but with just an on/off parameter. These are
easy to set up so long as the setup is already possible with /set_surface
--
Len Ovens
www.ovenwerks.net
More information about the Ardour-Dev
mailing list