Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER for macOS

Reply
 
Thread Tools Display Modes
Old 09-14-2016, 10:08 AM   #1
hermitcrab
Human being with feelings
 
Join Date: Jun 2014
Location: UK
Posts: 365
Default delayed response on track playback

Hi all,

Been banging on about this for 2 years but why is there a delay when changing parameters when mixing on playback in reaper even when no fx are active e.g. changing channel mutes on off incurs a ~1/4 - 1/2 second delay which is directly related to /caused by block size in audio settings. The longer the block size , the longer the latency. This surely shouldn't be happening as latency should only be occurring when tracking, not mixing and when mixing i always have latency / block size on max ( 1024 / 2048 ) to give more juice for fx. My understanding is that once the audio engine has caught up with the block size, everything should work without latency as the latency has already been taken care off when you press play ?

Anticipative fx and PDC compensation when monitoring do affect this also but i get noticeable latency when no fx are active and antic. fx turned off. it is directly caused by the block size in reaper. This is the case when using default audio drivers and with rme interface.

There should be no latency when changing parameters regardless of block size once the audio is already playing right ?

Would really appreciate some input with this from one of the dev's please as i've asked this question a few times ( and have learned stuff in doing so ) but the fundamental problem still exists. I love reaper but i never had a problem with cubase like this.

I'm on lion 10.7.5 and have had this problem with all reaper versions from 4.71 to current 5.22 version.

cheers for any help
hermitcrab is offline   Reply With Quote
Old 09-14-2016, 10:58 AM   #2
serr
Human being with feelings
 
Join Date: Sep 2010
Posts: 12,557
Default

Do you have the preference set for: "Do not process muted tracks."?

Because this turns the mute buttons into channel on/off buttons in function.
Turning a channel off removes it from the PDC calculation and the whole mixing board recalculates PDC. That means if you try to work the mute buttons (when in channel on/off mode) you get clicking/popping/lags as PDC is recalculated while audio is still playing.

Uncheck "Do not process muted tracks" and you get mute buttons again that you can use live.
serr is offline   Reply With Quote
Old 09-14-2016, 11:04 AM   #3
heda
Human being with feelings
 
heda's Avatar
 
Join Date: Jun 2012
Location: Spain
Posts: 7,239
Default

The solution is simple. Don't increase device buffer size to 1024 or 2048 while mixing if you really need no latency when mixing. If your system/CPU can handle it you don't need to give the plugins more room. Increasing the buffer size always increases latency which of course can be noticed when you modify a parameter of a plugin in real time.
heda is offline   Reply With Quote
Old 09-14-2016, 11:28 AM   #4
hermitcrab
Human being with feelings
 
Join Date: Jun 2014
Location: UK
Posts: 365
Default

Quote:
Originally Posted by serr View Post
Do you have the preference set for: "Do not process muted tracks."?

Uncheck "Do not process muted tracks" and you get mute buttons again that you can use live.
Good knowledge Serr thanks man, but i don't have this option ticked. Info underneath it states 'unmuting may not be instant with this checked'. This strongly suggests muting should be instantaneous, which for me it is not.

Can i ask, do you notice a slight lag even with no fx with higher block size please ?

Checked again and its not half a second, i think its a lot less but is related to block size. at 128 its pretty much instant and unnoticeable, but i work at 2048 when mixing.

cheers Serr
hermitcrab is offline   Reply With Quote
Old 09-14-2016, 11:40 AM   #5
hermitcrab
Human being with feelings
 
Join Date: Jun 2014
Location: UK
Posts: 365
Default

Quote:
Originally Posted by heda View Post
The solution is simple. Don't increase device buffer size to 1024 or 2048 while mixing if you really need no latency when mixing. If your system/CPU can handle it you don't need to give the plugins more room. Increasing the buffer size always increases latency which of course can be noticed when you modify a parameter of a plugin in real time.
Thanks for help but i am not referring to PDC but to audio buffer / block size latency compensation. I can find no reference to this in the user guide, only to PDC.

I may be wrong but that is not my understanding of how latency works.This latency occurs when no plugins are on any tracks. I thought latency ( audio buffer compensation ) occurs on initially playing the track back, not during, as then the latency has already been accounted for in the lag time between pressing play and the tracks actually playing ( hearing them ). Correct ?

From reaper user guide :

'As a rule, low levels of latency are only really needed for recording, not when you are only playing audio back. Therefore, if you find that you are pushing your CPU close to its limits, you will often be able to fix this by accessing your audio card’s control software and increasing the buffer size.'


To my knowledge there should be no difference between latency at 128 and 2048 when just playing audio back, but there does appear to be in reaper. I have not noticed this behaviour previously in cubase or logic pro x.

Ive noticed a few times this work around that you gave being suggested thanks, but it is common knowledge that mixing at higher buffers / block size is a good way to free up processing power when mixing as latency is then not a concern.

This strongly suggests to me that others have this problem also and that reaper is not compensating for block size / buffer latency initially ( i.e. before playback commences ) on playback like other DAW's ?

The latency is still present when media buffering is disabled ( in audio preferences ) and suggests to me the above.

To anyone ( including dev's ) - does reaper have audio buffer / block size latency compensation please ?

Last edited by hermitcrab; 09-14-2016 at 12:08 PM.
hermitcrab is offline   Reply With Quote
Old 09-14-2016, 12:00 PM   #6
heda
Human being with feelings
 
heda's Avatar
 
Join Date: Jun 2012
Location: Spain
Posts: 7,239
Default

REAPER does compensate latency that plugins can introduce, but there is no way REAPER or any other DAW that could anticipate what are you going to do in real time. All parameter changes that you automate can be anticipated and compensated. When you move a plugin parameter in real time while playing, you will hear it at least after the minimum latency that the driver dictates.
heda is offline   Reply With Quote
Old 09-14-2016, 12:03 PM   #7
serr
Human being with feelings
 
Join Date: Sep 2010
Posts: 12,557
Default

System latency is determined by the I/O buffer (called block size in Reaper).

Real simply, you give the computer "block size" # of samples to process the audio and spit it out. If anything takes longer than "block size" # of samples to process, you get underruns and hear that as clicks/pops. This really only comes up when trying to set the system for latencies under the threshold of perception for live sound work.

For anything where you aren't monitoring live inputs with live processed outputs, you set the latency to the max size. "Set it and forget it" to the max size to leave all CPU headroom for processing. Usually 1024 samples.

A 1024 sample block size (depending on the sample rate being used) is going to give you a system latency of around 20ms or so. This crosses the line and would be unusable for live sound needs of course but you aren't going to really notice a lag of 20ms just working knobs in post production.

Or...
If some job comes along where you need live sound-like instantaneous response to work some fx or something, switch the system to low latency for that job. Render stems if you need to free up CPU resources to do the live work and then switch back when finished.
serr is offline   Reply With Quote
Old 09-14-2016, 12:20 PM   #8
hermitcrab
Human being with feelings
 
Join Date: Jun 2014
Location: UK
Posts: 365
Default

Quote:
Originally Posted by serr View Post
System latency is determined by the I/O buffer (called block size in Reaper).

Real simply, you give the computer "block size" # of samples to process the audio and spit it out. If anything takes longer than "block size" # of samples to process, you get underruns and hear that as clicks/pops. This really only comes up when trying to set the system for latencies under the threshold of perception for live sound work.

For anything where you aren't monitoring live inputs with live processed outputs, you set the latency to the max size. "Set it and forget it" to the max size to leave all CPU headroom for processing. Usually 1024 samples.

A 1024 sample block size (depending on the sample rate being used) is going to give you a system latency of around 20ms or so. This crosses the line and would be unusable for live sound needs of course but you aren't going to really notice a lag of 20ms just working knobs in post production.

Or...
If some job comes along where you need live sound-like instantaneous response to work some fx or something, switch the system to low latency for that job. Render stems if you need to free up CPU resources to do the live work and then switch back when finished.
Thanks Serr,

I understand but if it is only 20ms or so lag ( that may be all i am experiencing at 1024 ) then will this not take place between pressing play and hearing audio ?

Will other DAW's have mute lags due to audio buffers ?

Honestly i'm not having a go at reaper but i used cubase for a while many years back and never experienced this behaviour and find it very difficult to automate mutes live due to the delay.

I thought audio latency compensation was a part of all DAW's, and is something different from PDC ? Am i wrong ?

cheers
hermitcrab is offline   Reply With Quote
Old 09-14-2016, 12:37 PM   #9
serr
Human being with feelings
 
Join Date: Sep 2010
Posts: 12,557
Default

Quote:
Originally Posted by hermitcrab View Post
Thanks Serr,

I understand but if it is only 20ms or so lag ( that may be all i am experiencing at 1024 ) then will this not take place between pressing play and hearing audio ?
Yes

Quote:
Originally Posted by hermitcrab View Post
Will other DAW's have mute lags due to audio buffers ?
Every DAW will have whatever lag you set it to with the I/O buffer.

Quote:
Originally Posted by hermitcrab View Post
Honestly i'm not having a go at reaper but i used cubase for a while many years back and never experienced this behaviour and find it very difficult to automate mutes live due to the delay.
That's why I thought you had the mutes set to on/off mode.

Quote:
Originally Posted by hermitcrab View Post
I thought audio latency compensation was a part of all DAW's, and is something different from PDC ? Am i wrong ?

cheers
"latency compensation" is a feature that automatically nudges all recorded audio back by to compensate for the system lag you have the I/O buffer set to + any inherent hardware lag in the system devices in question. You calibrate the "latency compensation" by doing a loopback test to get the exact latency value and then enter it in the preference setting. (PT, up to v9 anyway, didn't have this feature and it was a very welcome addition in Reaper when I upgraded.)

"PDC" (plugin delay compensation) is the feature that compensates for individual plugin latencies across all tracks and delays the least latent tracks so they all line up in phase at the output. Note: If the total PDC needed to correct the offset for any one track exceeds the I/O buffer size, Reaper doubles the I/O buffer to accommodate. THIS can be a cause of unexpected sudden double latency! Got some monster plugin on one of the tracks?

And of course, the bottom line minimum hardware/system latency is determined by the computer, it's I/O system, and the audio interface. There is no way to "compensate" for the minimum hardware lag beyond getting more powerful hardware.

Any of that help generate a clue?

Last edited by serr; 09-14-2016 at 12:43 PM.
serr is offline   Reply With Quote
Old 09-14-2016, 12:59 PM   #10
hermitcrab
Human being with feelings
 
Join Date: Jun 2014
Location: UK
Posts: 365
Default

Quote:
Originally Posted by serr View Post
Yes


Every DAW will have whatever lag you set it to with the I/O buffer.


That's why I thought you had the mutes set to on/off mode.


"latency compensation" is a feature that automatically nudges all recorded audio back by to compensate for the system lag you have the I/O buffer set to + any inherent hardware lag in the system devices in question. You calibrate the "latency compensation" by doing a loopback test to get the exact latency value and then enter it in the preference setting. (PT, up to v9 anyway, didn't have this feature and it was a very welcome addition in Reaper when I upgraded.)

"PDC" (plugin delay compensation) is the feature that compensates for individual plugin latencies across all tracks and delays the least latent tracks so they all line up in phase at the output. Note: If the total PDC needed to correct the offset for any one track exceeds the I/O buffer size, Reaper doubles the I/O buffer to accommodate. THIS can be a cause of unexpected sudden double latency! Got some monster plugin on one of the tracks?

And of course, the bottom line minimum hardware/system latency is determined by the computer, it's I/O system, and the audio interface. There is no way to "compensate" for the minimum hardware lag beyond getting more powerful hardware.

Any of that help generate a clue?
Thanks very much man, yes i think you've helped ( as always ). I think it is quite possibly just something i didn't notice before with cubase at 1024. in fairness i think i became 'sensitised' to it by antic. fx processing default being too high ( 200ms ) and then noticed some latency even with this turned off.

I think working at 2048 has just raised the problem again for me and i need to go back to 1024 block size.

cheers
hermitcrab is offline   Reply With Quote
Old 09-14-2016, 03:12 PM   #11
hermitcrab
Human being with feelings
 
Join Date: Jun 2014
Location: UK
Posts: 365
Default

Quote:
Originally Posted by serr View Post
"latency compensation" is a feature that automatically nudges all recorded audio back by to compensate for the system lag you have the I/O buffer set to + any inherent hardware lag in the system devices in question. You calibrate the "latency compensation" by doing a loopback test to get the exact latency value and then enter it in the preference setting.
Sorry Serr, last question. Which preference box is that please ? Is it just the block size you are referring to in audio device ?

cheers
hermitcrab is offline   Reply With Quote
Old 09-14-2016, 03:58 PM   #12
serr
Human being with feelings
 
Join Date: Sep 2010
Posts: 12,557
Default

Quote:
Originally Posted by hermitcrab View Post
Sorry Serr, last question. Which preference box is that please ? Is it just the block size you are referring to in audio device ?

cheers
That would be in Preferences/Audio/Recording

"Use driver reported latency" adds what the driver thinks/estimates/assumes the latency will be. Add an offset of your own to that or uncheck the box and only use your added offset.

The driver reported latency + a correction offset can be convenient sometimes. For one example, it might 'normalize' between two similar sample rates and allow you to use the same offset. You'll have to run loopback tests and play with your system to see where everything is at.
serr is offline   Reply With Quote
Old 09-14-2016, 04:28 PM   #13
hermitcrab
Human being with feelings
 
Join Date: Jun 2014
Location: UK
Posts: 365
Default

Quote:
Originally Posted by serr View Post
That would be in Preferences/Audio/Recording

"Use driver reported latency" adds what the driver thinks/estimates/assumes the latency will be. Add an offset of your own to that or uncheck the box and only use your added offset.

The driver reported latency + a correction offset can be convenient sometimes. For one example, it might 'normalize' between two similar sample rates and allow you to use the same offset. You'll have to run loopback tests and play with your system to see where everything is at.
Many thanks my friend
hermitcrab is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 04:51 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.