Sublab not correctly reporting latency to Ableton?

Hi! I’m new around here, hope you guys are all good.

I just picked up a copy of SubLab last week and there’s a lot I really like about it, but I’m trying to get my head around an issue I’m experiencing. I often use Live’s ‘resample’ feature to record Live’s output back into an audio track as a quick way of printing sounds. The issue I’m experiencing also occurs if I use ‘freeze/flatten’. And the issue is this:

Something seems to be going wrong where Live’s PDC is concerned - I’ve read that Live’s PDC is an odd implementation compared to other modern DAWs, but the behaviour I’m seeing I don’t see with other latency-inducing plugins.

When I print a bass sound from SubLab with delay compensation switched on, the front of the sound gets cut off, like so…


As you’d expect, this creates an audible pop at the start of the sound.

With delay compensation switched off, there’s a slight lag before the sound prints (as you’d expect), but it enables you to see what the initial transient of the sound should look like. I tried to post an image of this, but have just tried to post and have been told I can only embed 1 image. I’ll try to post the second image in as the first comment.

To me it looks like SubLab is reporting too much latency and Live is therefore shifting the audio too far in its attempt to compensate. (Note: I don’t know enough about this sort of stuff to know whether this is even theoretically possible, I’m just applying a best guess based on what I can see). There are no other plugins on the channel in question. Live is telling me that SubLab’s latency is 441 samples, but based on the ‘DC off’ print and using Psyscope to measure the period of silence (/lag) before the transient begins, it looks more like approx 250 samples.

Anyone else experiencing this issue? / @FAW team - is this something you’re aware of?

Thank you


Delay compensation switched off image…


Note: I’m using Live 11.1.5 on Windows 10

Have identified similar behaviour in Bitwig. In this screenshot you’ll see 4 channels.

  1. SubLab MIDI track - note where the MIDI note begins
  2. Audio track set to record output of SubLab channel - note where audio begins (too early)
  3. Miscellaneous break from sample library - note start position
  4. Audio track set to record output of track 3 - note start position matches audio in track 3

Hey @ol_tones,

Yes, we are looking into this topic right now :+1: Stay tuned for an update.

1 Like

awesome, yes will keep my eyes peeled! thank you

A bit of additional info in case it’s helpful; it looks as though SubLab is reporting dead on double the amount of latency it should be. If I delay my SubLab MIDI channel by 5ms (to offset the 10ms being reported), my recording starts at a zero crossing point. This is in v1.1.8.

Are there maybe some 2x oversampling shenanigans at play?

@ol_tones, no I think it is that we did some changes that resulted in an incorrect reporting in v1.1.8…we’re releasing a new beta next week so hang in there and we’ll have another out out for test then that will hopefully fix this.

Thanks again for the help!

1 Like