Forum rss-feed


Developers: Surprising Latency Measurements

Most Recent

written by: barnone

If anyone is interested, I posted the MAX patch in the OSC EigenD thread.

written by: barnone

Tue, 8 Nov 2011 18:11:33 +0000 GMT

Geert mentioned on this week's hangout that the CV solution with the OSC agent must be introducing unacceptable latency into the system.

I definitely follow his reasoning. The flow is raw OSC out of EigenD over udp network protocol going into MAX where it is sanitized and processed, then going back out of OSC via udp to ExpertSleepers plugin running in Ableton Live, then the expert sleepers plugins convert the OSC messages to CV audio inside of Live.

Stands to reason that this might be unacceptable, but I was saying to him that I had noticed no undue latency at all while playing. So this morning, I decided to try to measure it.

The setup is to measure it at the DAW. Now I know that this is not the same as measuring it at the audio interface which is where the cv ends up, however, it still is revealing.

The biggest surprise is regarding midi. The EigenD patch I'm using is sending both midi and OSC. Midi is going to an IAC internal midi port on OS X and then directly being recorded in Live. You'd expect the midi signal to have less latency than the multi-hop OSC flow, but this is not the case. I thought maybe that Live was doing delay compensation on the audio stream, however changing the audio buffer size in Live does NOT change the difference between the recording of the midi event and the OSC event.

The midi note is arriving 8 ms after the OSC converted cv audio in Live as shown below.

Midi vs OSC cv latency

This was surprising, so I decided to also record a piano sound coming from EigenD into Live via Soundflower. NOTE that there are two buffers involved here. EigenDs sample buffer size AND Live's buffer size. So buffer size is indeed a big factor. If EigenD was sending CV directly to an audio interface then it would involve only EigenDs buffer + the audio interface's buffer. And sending Expert Sleepers CV would add Live's buffer + the audio interface's buffer. So indeed direct out of EigenD would be faster by a buffer size just because of the audio routing involved.

Still, the double hop OSC signal is quite impressive. The midi timing is all over the place. The first OSC signal seems to come at a reliable offset. I don't know if it lags behind later when there is a lot of traffic. I do know that in playing with this a lot. I have yet to lose a note off message, which is something that happens often with midi.

Here are the audio latency differences with OSC CV audio on top and the recorded EigenD piano sound at the bottom with different buffer sizes.

64 sample buffer both sides

256 buffer both sides

512 Buffer Both Sides

The other interesting thing is that Expert Sleepers does seem to be decimating the data conversion. So we are seeing conversions at 10 ms intervals which is much slower than the 2000 events per sec flowing through the network and MAX. Meaning as well, that I can probable start decimating before sending OSC out of MAX.

Now the other big caveat is that someone is going to correct me here on the actual measurements as Live may be doing some delay compensation in recording that I don't understand the ramifications of.

written by: geert

Tue, 8 Nov 2011 18:21:20 +0000 GMT

Soundflower also has a buffer, don't forget that!

written by: barnone

Tue, 8 Nov 2011 18:30:33 +0000 GMT

I agree that the comparison with the piano audio is hard to make conclusions over. I guess I should send audio and cv out the audio interface and loop it back in to do a real measurement.

I still find the midi to cv comparison to be the most interesting.

written by: geert

Tue, 8 Nov 2011 18:38:54 +0000 GMT

That's interesting indeed!

I'll have to check why this might be happening. Maybe due to the implementation of the OSC agent it doesn't use the EigenD audio buffer, sending it out directly over the OSC network server instead of using the host audio clock ticks. MIDI might however be timed off of the host ticks. I'll have to talk it over with Jim though before I can say something about it with certainty.

written by: barnone

Tue, 8 Nov 2011 19:14:31 +0000 GMT

Well here's a much better measurement of the difference between CV arriving at the audio interface and audio from EigenD arriving at the audio interface.

In this case EigenD is sending to the same audio interface as Live, using the same buffer size.

I'm taking built in piano sound audio played on Eigenharp and cv outputs from expert sleepers and looping them back into the audio interface to record in Live.

Now we see a 48ms latency difference between the piano coming straight from EigenD and the CV arriving at the synth. Note that since CV cannot be recorded directly, the recording looks wonky but I think it still shows the timing.

So yeah, lot more latency. But the midi comparison is still surprising. Soundflower must add a lot of latency as well.

Loopback test

written by: geert

Tue, 8 Nov 2011 19:14:53 +0000 GMT

Thanks for measuring this, very interesting indeed. It does confirm that I want to make the effort on trying to add direct CV support, both to improve latency and to prevent decimation.

written by: dhjdhj

Tue, 8 Nov 2011 20:09:53 +0000 GMT

Two thoughts
1) IAC ports are not known for highly precise timing
2) Is Overdrive enabled in Max? That helps significantly with MIDI timing

written by: barnone

Wed, 9 Nov 2011 02:33:00 +0000 GMT

re 1: yeah but what would be faster, more reliable? not sending midi at all I imagine.
re 2: I wasn't routing midi through MAX at all, directly into Live via IAC port from EigenD. Good tip though with MAX.

It's definitely not clear where the latency occurs with the midi event.

Anyway, I'm not sure it matters in the end.

My takeaways are

#1 This little experimentation with an OSC to cv bridge has been quite informative and honestly, it's acceptable solution to me at the moment and very nice for experimentation and learning and prototyping.

#2 Way forward is to write an agent. Which is where this is headed probably.

The MAX way is still totally acceptable and I really think the results are great despite maybe some latency on the wire.

So we all win, maybe ;)

Also as a bit of a kudo to EigenD, system is incredibly impressive.

written by: barnone

Wed, 9 Nov 2011 16:13:29 +0000 GMT

If anyone is interested, I posted the MAX patch in the OSC EigenD thread.

Please log in to join the discussions