[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 

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 

> 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

More information about the Ardour-Dev mailing list