Pre vs post fx send does not affect performance

[brk303]

I use Reaper for live so efficient performance is important.

I've noticed that pre vs post fx sends do not seem to affect performance, which is what I would expect.

Given 2 record armed tracks, both with heavy fx, track A sends to B, changing between pre/post fx does not affect CPU usage.
Reaper should be optimized so that both track are processed in parallel if the send is pre fx, while they have to be processed in series with post fx send.

This could significantly improve real time performance if optimized correctly.

Any thoughts ?

[ramses]

If A sends to B, could they really be processed in paralLell?

[brk303]

Originally Posted by ramses

If A sends to B, could they really be processed in paralLell?

Logically yes, in case of pre-fx send.
Because processing of both tracks does not depend on processing of other track.

IOW, once A is blended in with B (as a result of pre fx send A->B) it can be processed by one thread while A is processed by another.

Only in case of Post fx send it has to be processed in serial fashion, one by one.

And Reaper should really take advantage of this.

[mschnell]

Originally Posted by brk303

I've noticed that pre vs post fx sends do not seem to affect performance, which is what I would expect.

Why do you think so, the effect chain output still goes to the master (or elsewhere) and potentially need to be calculated anyway.

To stop the plugins from being calculated you need to mute the track.

You might want to take a look at the sticky thread in the "live" forum for information on such issues.

-Michael

[brk303]

Originally Posted by mschnell

Why do you think so, the effect chain output still goes to the master (or elsewhere) and potentially need to be calculated anyway.

Where it goes doesn't matter, the question is what can be done in parallel. And pre fx sends could be processed in parallel.
Think about it, it's one pipe split into two, so it can be done in parallel.

Originally Posted by mschnell

To stop the plugins from being calculated you need to mute the track.

What's that got to do with anything ?

Originally Posted by mschnell

You might want to take a look at the sticky thread in the "live" forum for information on such issues.

I know the sticky stuff, I don't need help, I offer performance improvement suggestion, that's why I posted in here, didn't I explain well enough ?

[mschnell]

I in fact don't really understand your post.

In Reaper each track uses it's own OS thread and hence tracks can be calculated "in parallel" (provided there are multiple Cores working in the system).

This of course means that parallel processing is not perfectly exploited if you have e.g. one track with lots of plugins.

Is this what you mean ?
-Michael

[mschnell]

It is possible to define single plugins to use their own process (called "bridgíng") and hence enable them to use a free core. But the bridge transfer costs some additional CPU cycles.
-Michael

[brk303]

Originally Posted by mschnell

I in fact don't really understand your post.

Make two tracks, put heavy plugins on both and compare CPU usage when A->B is pre vs post fx. You will notice it does not change. If Reaper was properly optimized it would be lower with pre fx send.

Which part is unclear ?

Originally Posted by mschnell

In Reaper each track uses it's own OS thread and hence tracks can be calculated "in parallel" (provided there are multiple Cores working in the system).

I don't think it really works exactly like that, cores are not assigned exclusively to tracks, otherwise who would process 3rd track with 2 core CPU ?

So the link between tracks and cores is not a simple 1-1 mapping.

Originally Posted by mschnell

This of course means that parallel processing is not perfectly exploited if you have e.g. one track with lots of plugins.
-Michael

One track with many plugins is a sequential process so can only be handled by single core, because output of first plugin is input for second.

So it's not properly exploited because it's impossible.

It's same logic with what I'm describing, with pre FX, the FX of both tracks are independent and could be processed in parallel.

In this case multiple cores are also not exploited, but unlike sequential plugins, there's no logical reason for it here. So my post here is a plea to Reaper guys to implement this.

[ilarios]

I think I understand what the OP is saying, sending audio to another track pre-fx (if not armed) should be equivalent to copying the audio clip to said send, and with that allowing Reaper to process both tracks in parallel and independently (of course considering PDC).

I got curious so I started testing.

I tested with an "extreme" case, first I tried a single track with four instances of SirAudio StandardClip at x64 oversampling to get a sample of what a 100% serialized chain would do to the system resources: I immediately got underruns and the audio wouldn't play without artifacts (choppiness and skipping). I also noticed in the task manager that one core immediately hit 100%, while the other cores sat around 10-15% usage (Ryzen 7 3700x).

Here a screengrab of what the performance windows in Reaper reported:



I then tried to "split" the same chain into four parallel tracks: I sent the pre-fx audio to three different tracks and loaded all four (including the original source track) with one instance of SirAudio StandardClip at x64 oversampling; the first thing I noticed is that it took a bit more time before starting playing (I have set a pretty generous buffer for the anticipation fx processing), and then played without artifacts and without a single underrun. In task manager the difference was clear, four cores were hit at around 35% while the others stayed the same as before.

Here's what Reaper reported in this case:


(3 of the 4 reported fx inserts in track 2 Source were set to offline, so the total number of inserts used through all the tracks is still 4).

I then tested the same exact scenario but choosing post-fx in the send routing. This lead to the exact same results as the pre-fx test, same resource usage, and no underruns. There was also no change in the reported PDC.

That leads me to believe that Reaper does in fact process sends that receive pre-fx AND post-fx signal as parallel. I didn't expect the post-fx send routing to be perfectly parallelized, but there we go!
So kudos to the devs

Hope this helped in some way!

EDIT: Just realized you need the tracks to be Armed (for live usage), sorry!
Just tested that scenario and the results are as you described. I hit the same usage with both a single track with 4 inserts and 4 tracks with one insert each (all armed, I hit 250% RT CPU usage). I completely agree with what the OP asks, as the pre-fx send could really leverage the parallelization capabilities of Reaper. Put it this way: sending pre-fx should be equivalent to setting the receiving track's input the same as the source track, and that case would in fact be parallelized.

[brk303]

Originally Posted by ilarios

the pre-fx send could really leverage the parallelization capabilities of Reaper. Put it this way: sending pre-fx should be equivalent to setting the receiving track's input the same as the source track, and that case would in fact be parallelized.

Exactly, though technically it doesn't even have to be armed for this optimization to be applicable.
It's just that with rec armed tracks you are sure CPU usage is not affected by any look-ahead optimization.

In more practical terms, say I have a snare mic and I want to split it and process it it in 2 separate tracks so that one is gated and bright and other is more natural.

If I arm both tracks from same input, cpu usage is 24%:



Only first track armed, pre fx send to 2nd track, cpu usage is 43%


So CPU is 24% vs 43%, yet both method do exactly the same processing, and would even null.


To take it further let's say I have 3 tracks, one is armed, has no fx and sends to other two:


Here it's working efficiently, using 24% CPU.

So the conclusion is what I started the thread with, Reaper does not take advantage of pre vs post fx, which would help performance significantly.

More specifically it seems as if Reaper waits for track fx to complete processing even if it's sending pre process signal to pre fx output, which I would say is a bug.

So any track with pre fx send and some fx on it is not working efficiently !
Fortunately, there is a workaround, as shown in my pic #3. Add an extra input track which has no fx.

Ideally, Reaper engine would be fixed to figure it out automatically.

[mschnell]

Originally Posted by brk303

Make two tracks, put heavy plugins on both and compare CPU usage when A->B is pre vs post fx. You will notice it does not change. If Reaper was properly optimized it would be lower with pre fx send.

Seemingly you are somehow confusing latency and CPU performance usage in some way.

Latency could be less when the chains are in parallel than when they are serial. CPU performance is the same, as the tracks (each with one CPU) work on either the same or on different sample blocks, but both do work.

BTW.:
Latency is something that is set by the project configuration and setting it too low with too low CPU power results in crackling.
CPU performance usage is something that results from what the plugin take and does not influence the current latency, but the minimum latency number that can be set (e.g. by changing delay in the Audio Hawŕdware) in the project to avoid crackling.

-Michael

[brk303]

Originally Posted by mschnell

Seemingly you are somehow confusing latency and CPU performance usage in some way.

I have not talked about latency at all.

I perform live with my band through Reaper for few years now, I know what latency is and what I'm talking about. I am a software developer, I know threads and stuff too.

I don't want to sound rude, but could you try actually thinking about what I wrote ? You will see it makes sense.

I wrote another post shortly before your reply, maybe you didn't read it yet.

[mschnell]

OK. If you really mean CPU performance, the question does not make any sense at all.

- All plugins are calculated no matter in what order they are, hence the complete CPU performance (roughly) does not at all depend on any routing.
- If you have multiple cores (which you did not state) overall performance can be distributed among the cores and hence certain plugins can be calculated in parallel.
- Reaper (if not briding) uses an OS thread per track and hence (unless the plugins open their own CPU threads) at most as many cores as tracks can be used for audio.
- When using bridging for a plugin same can use an additional core.
- There is no difference between routing to another track pre or post FX chain. The tracks will each use a core (if available) anyway. The only difference is that with pre-FX routing they at the same point in real time will work on roughly the same "counted order" sample block, while with post FX routing they will work definitiveĺy on different "counted order" sample blocks.


-Michael

[brk303]

Originally Posted by mschnell

- All plugins are calculated no matter in what order they are, hence the complete CPU performance (roughly) does not at all depend on any routing.

This is incorrect, as can be seen in the screenshots I posted.
Same plugins but different RT CPU usage depending on the routing (24% vs 43% RT CPU)

Originally Posted by mschnell

- If you have multiple cores (which you did not state)

Dude, I have my whole band playing live through Reaper, and you ask if I have a multiple core cpu ?

Anyone else ?

[mschnell]

Originally Posted by brk303

This is incorrect, as can be seen in the screenshots I posted.

I have no Idea how overall CPU performance can be influenced (largely) by routing.

Maybe a measurement problem ?

(Measuring the the summed performance of multiple cores is tricky to say the least)

-Michael

[brk303]

Originally Posted by mschnell

Maybe a measurement problem ?

There is no measurement problem, the CPU usage really does change.