Latency with max4live devices

Sep 18, 2010 at 4:50pm

Latency with max4live devices

I built a m4l device which gates the signal at a synced rate (i.e. 1/4). I have several other m4l devices in this liveset as well. Depending where in the effect chain this gater-effect is placed there is more or less latency involved, which is not compensated. This means that the gater-effect is i.e. too late.
Does anyone know of a solution to automatically compensate latency?

#52374
Sep 19, 2010 at 1:36am

Automatic latency compensation in Live (and other DAWs) aligns the latency among different *tracks*. Technically, this can be easily be implemented by delaying some tracks such that all tracks have the same latency.

Latency among different devices on the same track is a new problem specific to M4L, in particular with synced devices. It’s another level of complexity and I think that automatic compensation would be very difficult to implement, if possible at all.

#188241
Sep 19, 2010 at 12:24pm

So, here is a simple example to demonstrate and investigate the issue.

Take an M4L audio device that generates clicks on the beat, and load 2 instances one after the other on the same track. When running you’ll notice that the clicks are not in sync. However, sync can be achieved by delaying the second instance. On my system it requires a delay of 13.6ms (at 512 audio buffer size).

In theory, this “device delay compensation” may also be done automatically by introducing appropriate sync delay depending on the actual position of a device within the chain. But the feasibility can only be estimated by developers..

For anybody interested, here is a click generator patch with adjustable delay. As described above, it can be used to measure the actual delay per device in a chain of your setup.

– Pasted Max Patch, click to expand. –
#188242
Oct 20, 2010 at 2:15pm

Hello.
Interesting topic. I already noticed that when a new live set is instanciated, there is an overall audio latency which is increasing while adding tracks / devices / clips to this set. We noticed that in syncing two computers with a clock and adding new tracks / devices on each ableton instance.

Is it possible to get the value of the new global latency from a M4L patch right after dropping new tracks / devices ?

#188244
Oct 20, 2010 at 10:26pm

I think automatic measuring would be difficult but you can estimate it. The global latency is determined by the track that contains a chain with the highest number of M4L devices. Each device added to that chain will add to global latency by an amount proportional to audio buffer size.

#188245
Oct 20, 2010 at 11:06pm

“Technically, this can be easily be implemented by delaying some tracks such that all tracks have the same latency.”

what most audio apps do is to pre-delay the track with the plug-in by reading
files from disk earlier, or by shortening the track buffer.

delaying all other tracks sound more like a worksround solution in emergecy cases.

-110

#188246
Oct 21, 2010 at 9:24am

Yes, shortening the track buffer is an elegant solution which works for conventional setups, but probably not with M4L since in general you can have multiple devices in a chain on the same track. For example, with 8 devices in the chain and buffer size of 128 samples, the shortened buffer would be only 16 samples.

#188247
Oct 21, 2010 at 9:53am

i think live is fixed at 64 samples isn’t it? i’m very interested, so that was not really a rhetorical question and please correct me if i’m wrong

#188248
Oct 21, 2010 at 10:03am

No, in the audio preferences you can choose any buffer size from 14 to 2048.

#188249
Oct 21, 2010 at 2:33pm

yes, sorry, i was offtopic, thinking about vector size…

#188250
Apr 14, 2012 at 5:54am

There’s also the “Defined Latency” value in the device’s inspector. (not to wake the zombies, just in case anyone else ends up here)

#188251
Apr 20, 2012 at 7:17pm

as I understand it, The delay increases as you go down the effect chain. Although audio may be delay compensated, it still takes x + y + z samples to process where these are the respective delays for your chain. So if your device is first, it will be processing audio when the buffer request for audio is called. If you can, try putting it first and seeing if that changes how it’s working, it would be interesting to know…

#188252

You must be logged in to reply to this topic.