My dsp Meter was running in the reds, then I bought an extra 8gb memory stick. I have 16GB ram now, but it's JUST as bad as before. Which is extremely annoying.
My multicore rendering is on btw, always has been.
I'm not a great techie, but shouldn't this have brought upon an improvement?
Any ideas? Anything I can do to squeeze out the max?
So how come taskmanager says cpu usage is around 40% but my DSP meter is in the red?
Its because DSP load *is not* the same as CPU load.
What the DSP meter shows is a percentage of the time of one buffer (e.g. 512 samples at 44.1kHz) - the time the computer needs to process the data and output it again. If the computer needs more than the time of the buffer the DSP meter is at 100% and the buffer can't be delivered in time - you get crackles and dropouts.
The time the computer needs is in part depending on the CPU power - a lot of the processing is simple number crunching. However there can be many other things that take time - transferring data from the USB bus, copying it in memory etc. On top of that the computer does all kinds of other work that might require the CPU to do work that isn't actually crunching numbers.
So in the end there can be all kinds of things driving up your DSP load without the CPU doing much at all.
Edit: Usually upping the buffer size will make the percentage of time needed for other things lower. E.g. your CPU might spend half a millisecond doing USB stuff, thats a relatively big part of a 64 sample buffer and not much of a 512 sample buffer.
What the DSP meter shows is a percentage of the time of one buffer (e.g. 512 samples at 44.1kHz) - the time the computer needs to process the data and output it again. If the computer needs more than the time of the buffer the DSP meter is at 100% and the buffer can't be delivered in time - you get crackles and dropouts.
The time the computer needs is in part depending on the CPU power - a lot of the processing is simple number crunching. However there can be many other things that take time - transferring data from the USB bus, copying it in memory etc. On top of that the computer does all kinds of other work that might require the CPU to do work that isn't actually crunching numbers.
So in the end there can be all kinds of things driving up your DSP load without the CPU doing much at all.
Edit: Usually upping the buffer size will make the percentage of time needed for other things lower. E.g. your CPU might spend half a millisecond doing USB stuff, thats a relatively big part of a 64 sample buffer and not much of a 512 sample buffer.
My DSP meter usually only spikes when I'm loading a project and it has large wav samples in it.
I did notice a HUGE increase in performance in this regard when I went to SSD drives for the OS. So if you have an HDD, you should seriously consider making the swap.
I did notice a HUGE increase in performance in this regard when I went to SSD drives for the OS. So if you have an HDD, you should seriously consider making the swap.
normen wrote: ↑16 Oct 2017Its because DSP load *is not* the same as CPU load.
What the DSP meter shows is a percentage of the time of one buffer (e.g. 512 samples at 44.1kHz) - the time the computer needs to process the data and output it again. If the computer needs more than the time of the buffer the DSP meter is at 100% and the buffer can't be delivered in time - you get crackles and dropouts.
The time the computer needs is in part depending on the CPU power - a lot of the processing is simple number crunching. However there can be many other things that take time - transferring data from the USB bus, copying it in memory etc. On top of that the computer does all kinds of other work that might require the CPU to do work that isn't actually crunching numbers.
So in the end there can be all kinds of things driving up your DSP load without the CPU doing much at all.
Edit: Usually upping the buffer size will make the percentage of time needed for other things lower. E.g. your CPU might spend half a millisecond doing USB stuff, thats a relatively big part of a 64 sample buffer and not much of a 512 sample buffer.
Oke so I get that. I'll lower my buffer size. But how about the new 8gb stick. What kind of uptick in performance should be expected? Shouldn't that have made a huge enough of a difference for the song to not crackle anymore? And also, is there a good way to measure weather I max the ram out?
- CephaloPod
- Posts: 268
- Joined: 16 Jan 2015
RAM won't give you better performance in Reason at all, unless you are using large sample libraries.
2011 iMac i7; 24 GB RAM; OSX Sierra; Nektar LX 49; MOTU Microbook
Reason/Logic
Reason/Logic
So basically upgrade the processor to an i7 that supports hyperthreading or suck it up ?CephaloPod wrote: ↑16 Oct 2017RAM won't give you better performance in Reason at all, unless you are using large sample libraries.
-
- Posts: 17
- Joined: 04 Jun 2017
Reason isn't my main daw but I remember a setting to change reason's cpu usage percentage. Change it to 100% I think the default is 95%.
Increase your buffer time as normen mentioned.
messy-jesse.com
Increase your buffer time as normen mentioned.
messy-jesse.com
- pedrocaetanos
- Posts: 252
- Joined: 16 Jan 2015
- Location: LX Portugal
- Contact:
The default is 80%.messy-jesse wrote: ↑17 Oct 2017Reason isn't my main daw but I remember a setting to change reason's cpu usage percentage. Change it to 100% I think the default is 95%.
Increase your buffer time as normen mentioned.
messy-jesse.com
Anyway, if this would help, it would only give 20% more "DSP power".
Based on a true story. No Musical Instruments Were Harmed in the Making of This Forum Post. | SoundCloud set |
- pedrocaetanos
- Posts: 252
- Joined: 16 Jan 2015
- Location: LX Portugal
- Contact:
Not lower. Increase. Normen advice is probably your best solution.
From the Reason manual:
The trick here is to find the optimum relationship between audio quality, DSP Load and latency. Experiment with different
Sample Rate settings in combination with different Buffer Size settings to get the best result.
A professional audio interface used together with a state-of-the-art computer should normally be able to handle a
combination of a high sampling frequency (96 kHz) and a small Buffer Size (64-128 samples) without problems. A
budget priced audio interface normally requires a lower sampling frequency (44.1 kHz) in combination with a little
higher Buffer Size (256-512 samples).
None, it's as CephaloPod said. These days, after you have 4 GB Windows won't get much faster, and it will only server for applications starving for memory.
No. RAM has no effect whatsoever in crackles.
Your print-screen seems Windows 8 or 10. If so, it's where you see CPU load, in Task Manager, "More Details".
In the "Performance" separator you get a detailed overview, but it may be more important to see in "Processes" separator how much CPU and memory Reason is consuming.
Based on a true story. No Musical Instruments Were Harmed in the Making of This Forum Post. | SoundCloud set |
- Carly(Poohbear)
- Competition Winner
- Posts: 2871
- Joined: 25 Jan 2015
- Location: UK
Also what is you machine spec, more interested in CPU and speed.pedrocaetanos wrote: ↑18 Oct 2017Not lower. Increase. Normen advice is probably your best solution.
From the Reason manual:
The trick here is to find the optimum relationship between audio quality, DSP Load and latency. Experiment with different
Sample Rate settings in combination with different Buffer Size settings to get the best result.
A professional audio interface used together with a state-of-the-art computer should normally be able to handle a
combination of a high sampling frequency (96 kHz) and a small Buffer Size (64-128 samples) without problems. A
budget priced audio interface normally requires a lower sampling frequency (44.1 kHz) in combination with a little
higher Buffer Size (256-512 samples).
None, it's as CephaloPod said. These days, after you have 4 GB Windows won't get much faster, and it will only server for applications starving for memory.
No. RAM has no effect whatsoever in crackles.
Your print-screen seems Windows 8 or 10. If so, it's where you see CPU load, in Task Manager, "More Details".
In the "Performance" separator you get a detailed overview, but it may be more important to see in "Processes" separator how much CPU and memory Reason is consuming.
When in the performance tab, make sure you right click on the graph and select logical processors..
and a print screen \snippet capture of the first 2 pages from Reason Preferences.
Hey, but do not get rid of the ram.
As you can run VST's, and Reason samples do not have HDD streaming, more ram means you can run more Sample player instances.
Anyway, a good option is to separate production stages to ease the CPU. After arranging and recording your audio, bounce every midi track to to another track and delete the sources, or use a dummy device (make a backup file first), then mix in this new file over the bounced tracks.
Finally do the same for mastering - export a stereo track of each song and load them to a new reason project, and master multiple songs in one project. This "technique" is used by most pro's ages ago! It not only helps to ease the CPU usage, as it will make you separate context (i always preferred this opposite to freese tracks and even if my PC can stand the project load i always work with another project for mastering at least).
Cheers and good luck!
As you can run VST's, and Reason samples do not have HDD streaming, more ram means you can run more Sample player instances.
Anyway, a good option is to separate production stages to ease the CPU. After arranging and recording your audio, bounce every midi track to to another track and delete the sources, or use a dummy device (make a backup file first), then mix in this new file over the bounced tracks.
Finally do the same for mastering - export a stereo track of each song and load them to a new reason project, and master multiple songs in one project. This "technique" is used by most pro's ages ago! It not only helps to ease the CPU usage, as it will make you separate context (i always preferred this opposite to freese tracks and even if my PC can stand the project load i always work with another project for mastering at least).
Cheers and good luck!
BTW, upgrading to a I7 is a good idea, but keep in mind that you must activate the Multi Threading and it is only available in Reason 9.5.2.
You must try to see if the setting is good for your PC. I found that the hyper threading option makes reason and the whole computer behave more inconsistently. Another thing i noticed is that Hyper Threading in reason is not effective for every projects. It will help a lot projects with lots and lots of Synths, but sample based projects or with a lot of audio seem not to get much advantages and they will load much DSP and CPU with hyper threading active.
Mind that these were things i discovered with my tests on Reason hyper threading settings and you might find completely different results. Intel Chips work HT differently from AMD, and even different Intel Chips can behave differently.
Still it is great to know Propellerheads is trying to solve Reason performance issues.
Again,
Good Luck.
MC
You must try to see if the setting is good for your PC. I found that the hyper threading option makes reason and the whole computer behave more inconsistently. Another thing i noticed is that Hyper Threading in reason is not effective for every projects. It will help a lot projects with lots and lots of Synths, but sample based projects or with a lot of audio seem not to get much advantages and they will load much DSP and CPU with hyper threading active.
Mind that these were things i discovered with my tests on Reason hyper threading settings and you might find completely different results. Intel Chips work HT differently from AMD, and even different Intel Chips can behave differently.
Still it is great to know Propellerheads is trying to solve Reason performance issues.
Again,
Good Luck.
MC
If you have enough effects and stuff on one bus, it will only operate on one core, and thus max it out, and not the other cores, since the processing on the signal chain on one bus cannot be divided across cores. Task manager on the other hand shows the total capacity and load of all the cores.
Can you show what your signal flow is and what you have loaded + system specs?
Can you show what your signal flow is and what you have loaded + system specs?
-
- Information
-
Who is online
Users browsing this forum: DotNetDotCom.org [Bot] and 24 guests