REAPER - Mysteriously CPU rises with a BLANK SECTION in a track

fastonebaz

I have a weird thing going on in REAPER (unlicensed).  Windows / Dell XPS 2019 decent spec / Steinberg URII Mk2

I have a project with 15 tracks and a bunch of compression, eq and guitar amp sims spread around.  And something is happening that i don't understand.

Playing the timeline shows various tracks using about 1.5% of CPU each and playback audio is fine.

BUT.....

Then it gets to a passage in the song with track 5 has a gap for about 30s - e.g. there is no waveform as that track doesn't have anything to play, and during that gap, the CPU for that track rockets to 8.5% and causes all manner of audio buffering.  As soon as it passes the gap and a waveform appears, CPU goes back down to 1.5% and audio resumes playing fine.

If I solo track 5, CPU is 1.5% where there's audio and it rockets to 8.5% during the gap with no audio.  If I mute track 5, playback shows it consuming 0% CPU as expected.  

Yes sure I can keep increasing the sample buffer size until audio plays back fine throughout but that isn't my question.

My question is, why is CPU % rocketing in the track gap where there is no audio to process?   Does that happen to everyone?  Is that normal?  Can I stop it from occurring?  Seems weird to me.

Winny_Pooh

Is the problem perhaps that the gap means the next waveform is a different file on your disk? Try consolidating your tracks, then delete the old fragments and see if it continues. 

fastonebaz

@Winny_Pooh ;
Yes - part 1 of track 5 and part2 of track 5 are different WAV files.

However, since the gap between them is 30s I can't see why CPU usage increase so much when there's no audio and then goes back to a tiny level from part2 comes in.

WiresDreamDisasters

Possible denormalization issue? What plugins are you using?

mudslide73

Yeah.. I'd disable your plugins in turn to narrow it down. Also I've had buffering when I have the UI for a resource hungry plugin open but none when it's minimised.

fastonebaz

No plugin ui open, surely when there's no audio or waveform on a track cpu shouldn't go up though on that track (no matter what the plugin), it should kind of bypass mode it when there's nothing to process.  Especially when the cpu goes back down when the waveform comes into play.

It weird how all the other tracks which do have audio continue around 1.5% whilst track 5 with no audio balloons. Bonkers.  

digitalkettle

Can another Reaper user import your project to see if they can repeat the issue? (I’m not a Reaper user)

stratman3142

digitalkettle said:

Can another Reaper user import your project to see if they can repeat the issue? (I’m not a Reaper user)

I'm happy to try it on my system in Reaper.

WiresDreamDisasters

fastonebaz said:

No plugin ui open, surely when there's no audio or waveform on a track cpu shouldn't go up though on that track (no matter what the plugin), it should kind of bypass mode it when there's nothing to process.  Especially when the cpu goes back down when the waveform comes into play.

It weird how all the other tracks which do have audio continue around 1.5% whilst track 5 with no audio balloons. Bonkers.  

If a plugin has denormalisation issues, it could cause CPU to be munched through even when not in use.

PolarityMan

Really interesting article on denormalisation here:

http://ldesoras.free.fr/doc/articles/denormal-en.pdf

Definitely sounds like the issue you are describing. I had no idea this was a thing until just now.  Have you narrowed it down to a specific plugin? 

fastonebaz

I'll have a look into the denormalization issue tonight..... when my studio / office cools down below 900000000000 C.

andy_k

denormalising, as described in that article, is beyond my comprehension, if I was having this problem I would either render the track as new track with or without plugins, or put the different wav files on individual tracks and use the plugins on a folder.
I will have a look at one of my projects tomorrow to see if I can see this type of behaviour on tracks with silent passages, I do a lot of editing within a track and usually split and mute sections, so it will be interesting to see if this is an issue.
I tend to split tracks and use either mute or clip volume instead of automation and have not had any noticeable issues, I would expect some by splitting, but cannot say I hear any negative affect.

fastonebaz

Well, track 5 has 3 plugins on it, and when there's no audio for 30s the cpu increases from 1.5% to 8.5% and goes back to 1.5% when it reaches the next  audio part on that track.  Of the 3 plugins its the BiasFX2 plugin that created this effect, the other 2 make no different when isolated.  I can work around this in balls ways but I just don't get why its happening when there's no audio.  Can't find any info on denormalization relating to that.   

Cheers @stratman3142 for the offer but no need ta 

siremoon

You're kind of assuming that a DAW does nothing when there is no audio to render on a given track.  That is not necessarily always the case.  Audio processing is quite hard work so anything that a DAW can do to spread the processing load out is going to improve performance.  For example Reaper has a feature which allows Fx processing on a track to be done early if that track's dependencies on other tracks allow it and it is advantageous to the overall playback performance to do it early.  One time where it might be advantageous is when a track is silent.  I'm not saying that is what is happening here but the assumption that cpu usage of a track is always directly related to when you can hear that track is not necessarily correct. 

You don't actually say definitively if whatever is happening here is causing you a problem or not.  If it isn't I wouldn't worry about it.

fastonebaz

@siremoon now that sounds like an interesting possibility.   Given that on track 5 there are 2 sections of audio, section 1 is one take,  then a gap for 30s of nothing and section 2 is a different take.  Maybe during the gap its down some forward processing on the upcoming take2 on track5.  That sounds logical and possible. Hmm.

Its a problem. In the sense that because of this,  during mixing I have to increase the sample rate to 2048 so everything plays smoothly.  Without that issue I'd be down at 512 without issue.  However since sample rate isn't an issue when mixing its not a real problem.

I was just baffled why its occurring when there was no audio to process.

andy_k

I try to do my mixing work with Reaper processing at about 20-30%, so if I have tracks using VST instruments or heavy effects, I will render them as audio, often then I will strip out silence by muting sections, so I will see if there is any effect on processing by doing that.
My workflow is dictated by my hardware, so it is a good excuse to commit to things.
I don't think I have ever had samples set above 512 for mixing, but do have to go down to 64, or even 32 for tracking.
There are a lot of vids on the Reaper home page, some of them may help to understand the background process.

andy_k

Just having a look,
My track is a cover of 'here comes the rain again' with string parts done with VSTi like Spitfire Labs.
I have these tracks rendered as wav, and am working on a stem mix, all audio files, drums, bass and strings.
I have the stems running into a mix bus with Slate VMR running, Mix bus runs into Master bus with Fabfilter ProMB, and Slate FGX. There is also an instance of Eoisis Air eq on Mix Bus.
Each string track has Fabfilter proQ3, and I have them bypassed. One string track has Valhalla supermassive on it, also bypassed.
With the track idling, nothing playing, CPU reads 17.1%, with all tracks playing it is running at about 22.5%.
The two string tracks are showing 0.0 cpu use, with no plugins running.
FF ProQ adds 0.06%, and Valhalla adds about .35% to the track and .5% to idle total-so 17.5%. With these plugins active the track is running at around 24%.
Both these string parts are strip silenced by slicing and muting sections, and CPU does not vary from idling to playback, there is no variance when playing over silent passages.
I realise this is not exactly the scenario you have, but it illustrates my point, it is probably one of your plugins that is causing the issue--I am using Valhalla with a long reverb, which probably exaggerates the issue for me here, and it is interesting how much the system uses in an idle state, I have a lot of tracks and folders muted, and some of the VSTs are offline while I am mixing.
It is a 48k, 24 bit session, with a 512 buffer.
This mix was then 'mastered' by using FGX to get loudness up to around 13 RMS, peaking at -.3, and then rendered as a 16 bit 320k MP3.
It's not a commercial mix, and I am very much still learning, but my workflow works for me here.
Reaper is usually faultless, and the only problems come from certain plugins, this is my first mix with Valhalla supermassive, and I do like it a lot.

WiresDreamDisasters

fastonebaz said:

Well, track 5 has 3 plugins on it, and when there's no audio for 30s the cpu increases from 1.5% to 8.5% and goes back to 1.5% when it reaches the next  audio part on that track.  Of the 3 plugins its the BiasFX2 plugin that created this effect, the other 2 make no different when isolated.  I can work around this in balls ways but I just don't get why its happening when there's no audio.  Can't find any info on denormalization relating to that.   

Cheers @stratman3142 for the offer but no need ta 

Almost 100% that's a denormalization issue.

PolarityMan

andy_k said:

denormalising, as described in that article, is beyond my comprehension, if I was having this problem I would either render the track as new track with or without plugins, or put the different wav files on individual tracks and use the plugins on a folder.
I will have a look at one of my projects tomorrow to see if I can see this type of behaviour on tracks with silent passages, I do a lot of editing within a track and usually split and mute sections, so it will be interesting to see if this is an issue.
I tend to split tracks and use either mute or clip volume instead of automation and have not had any noticeable issues, I would expect some by splitting, but cannot say I hear any negative affect.

Basically the representation that the computer uses internally for number has to change for very very small numbers and this means they are less efficient to process. Its a bit of a hole in the VST spec tbh as the levels of precision we're talking about are well below the threshold of hearing. 

PolarityMan

fastonebaz said:

@siremoon now that sounds like an interesting possibility.   Given that on track 5 there are 2 sections of audio, section 1 is one take,  then a gap for 30s of nothing and section 2 is a different take.  Maybe during the gap its down some forward processing on the upcoming take2 on track5.  That sounds logical and possible. Hmm.

Its a problem. In the sense that because of this,  during mixing I have to increase the sample rate to 2048 so everything plays smoothly.  Without that issue I'd be down at 512 without issue.  However since sample rate isn't an issue when mixing its not a real problem.

I was just baffled why its occurring when there was no audio to process.

Im not a big fan of bias...only reason I ever use it is if the other guitarist in my band sends me a session

andy_k

PolarityMan said:

andy_k said:

denormalising, as described in that article, is beyond my comprehension, if I was having this problem I would either render the track as new track with or without plugins, or put the different wav files on individual tracks and use the plugins on a folder.
I will have a look at one of my projects tomorrow to see if I can see this type of behaviour on tracks with silent passages, I do a lot of editing within a track and usually split and mute sections, so it will be interesting to see if this is an issue.
I tend to split tracks and use either mute or clip volume instead of automation and have not had any noticeable issues, I would expect some by splitting, but cannot say I hear any negative affect.

Basically the representation that the computer uses internally for number has to change for very very small numbers and this means they are less efficient to process. Its a bit of a hole in the VST spec tbh as the levels of precision we're talking about are well below the threshold of hearing. 

Thanks, I tried reading it again, but it might as well be written in Klingon.
There are ways to correct the 'problem' it seems, ie adding white noise, but I think the problem lies with a bad plugin and is not a Reaper problem.
So the simple solution, is render to audio, or use a different plugin surely.