Old 01-11-2019, 01:33 PM   #41
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 23,170
Default

Quote:
Originally Posted by poetnprophet View Post
It seemed to work pretty well when mixing, getting some slight CPU decrease. But for recording live it seems to be counter-productive.

So tonight i will revert my settings to default and hope that gets me back to where I was.
Just a couple points... The RT CPU (as coachz mentioned) is where it matters, that lives on a single CPU core, and if you had say 4 cores, the OS showing 25% could mean one that one core is maxed at 100% aka 25% of 4 cores. That will cause glitches because the audio driver thread (RT CPU) can only live on one core.

Lastly, unless you have a specific need (such as I mentioned further up in another post) always mix at the highest buffer setting available as there is little benefit to low-latency if not recording and monitoring through reaper. On that note, if you aren't monitoring through reaper when tracking (I monitor through my sound card mixer whenever possible) you still don't need small buffers - the only time small buffer are needed are when you need to monitor through reaper such as through an amp sim or VSTi in real time - or you have automation that needs to occur in less that 20ms or so (rare in my world).

Lastly, lastly... I suggest testing one perf setting change at a time, I've made very few changes over the years - there should be a happy medium but it can be a bit of a combination lock because no two systems/user setups/needs are the same. I've found that to be true in every DAW I've ever used but this is because such real-time low-latency is rarely needed by any other type of application outside of DAWs and audio.
karbomusic is offline   Reply With Quote
Old 01-11-2019, 03:16 PM   #42
Magicbuss
Human being with feelings
 
Join Date: Jul 2007
Posts: 1,609
Default

Quote:
Originally Posted by Coachz View Post
1024 is a big buffer!
1024 is the recommended buffer size for mixing and will reduce CPU usage.

Only go lower if you need to record with low latency.
Magicbuss is offline   Reply With Quote
Old 01-11-2019, 03:33 PM   #43
poetnprophet
Human being with feelings
 
poetnprophet's Avatar
 
Join Date: Jan 2018
Posts: 380
Default

Quote:
Originally Posted by karbomusic View Post
Just a couple points... The RT CPU (as coachz mentioned) is where it matters, that lives on a single CPU core, and if you had say 4 cores, the OS showing 25% could mean one that one core is maxed at 100% aka 25% of 4 cores. That will cause glitches because the audio driver thread (RT CPU) can only live on one core.

Lastly, unless you have a specific need (such as I mentioned further up in another post) always mix at the highest buffer setting available as there is little benefit to low-latency if not recording and monitoring through reaper. On that note, if you aren't monitoring through reaper when tracking (I monitor through my sound card mixer whenever possible) you still don't need small buffers - the only time small buffer are needed are when you need to monitor through reaper such as through an amp sim or VSTi in real time - or you have automation that needs to occur in less that 20ms or so (rare in my world).

Lastly, lastly... I suggest testing one perf setting change at a time, I've made very few changes over the years - there should be a happy medium but it can be a bit of a combination lock because no two systems/user setups/needs are the same. I've found that to be true in every DAW I've ever used but this is because such real-time low-latency is rarely needed by any other type of application outside of DAWs and audio.
RT CPU at the time of the issues was about 20%. When recording vocals, I use 64mb buffer for the lowest latency and performance for recording only through Reaper and plugins. When mixing I'm at 512, 1024 for a large project...and not recording at all.

Agreed, changing settings was not really a good idea as I don't know what I'm doing and I'm pretty sure that was the culprit (i'll confirm later). My point being that, what works for some computers/workflows won't work for all....and I think someone else mentioned that also. Don't go blindly changing things like I did just based on what you read.
poetnprophet is online now   Reply With Quote
Old 01-14-2019, 11:54 AM   #44
poetnprophet
Human being with feelings
 
poetnprophet's Avatar
 
Join Date: Jan 2018
Posts: 380
Default

confirmed it was the multi fx and thread processing settings, I actually left the behavior at default. Switched back to default buffer settings and all is well again. Whew.
poetnprophet is online now   Reply With Quote
Old 01-14-2019, 03:40 PM   #45
ChristopherT
Human being with feelings
 
Join Date: Apr 2017
Location: South
Posts: 401
Default

Do any of you ever use 2048 block size?
ChristopherT is offline   Reply With Quote
Old 01-14-2019, 04:25 PM   #46
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 23,170
Default

Quote:
Originally Posted by ChristopherT View Post
Do any of you ever use 2048 block size?
Yep, if it's in the list of choices, I usually run 1024 since that's the highest available @48k with my RME UFX. I never use anything but the highest setting unless I have to monitor through reaper when tracking - beyond that there is almost zero benefit to mixing at low latencies (see a couple posts up of mine for a couple exceptions to that rule). There may be other exceptions based on use case but generally, mix at the highest instead of unnecessarily wasting CPU cycles.
karbomusic is offline   Reply With Quote
Old 01-14-2019, 06:01 PM   #47
ChristopherT
Human being with feelings
 
Join Date: Apr 2017
Location: South
Posts: 401
Default

I have my mix set-up at 2048.

Can someone please explain what negatives a really high block size has?
(like 4096? - or larger?)

I understand the low size/recording for latency, but what exactly is the block size setting doing?
Is it setting aside ram for mix processing ?

I'm using a RME MadiFace + SSL AlphaLink Madi AX - MacPro 8Core 64g Ram.

But still unsure how far to push the block size for huge track count mixing, and how this may affect overall performance / plug in counts - or Ram?
ChristopherT is offline   Reply With Quote
Old 01-14-2019, 10:43 PM   #48
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Germany
Posts: 6,333
Default

Delay after pressing play (or stop) .

Delay between what you see on the screen and whyt you hear.

-Michael
__________________
www.boa-sorte.de
mschnell is offline   Reply With Quote
Old 01-15-2019, 02:11 AM   #49
akademie
Human being with feelings
 
Join Date: Mar 2007
Posts: 363
Default

Quote:
Originally Posted by ChristopherT View Post
Can someone please explain what negatives a really high block size has?
(like 4096? - or larger?)
Quote:
Originally Posted by mschnell View Post
Delay after pressing play (or stop) .
Delay between what you see on the screen and whyt you hear.

-Michael

Also all automation data and parameter modulations will not be time precise/accurate as with low buffers (lets say 256 and lower)

Although it may not be problem for normal track envelopes, it can be very prominent if you try to modulate e.g. Cutoff of filter as FilterEnvelope with sharp attack - try to change blocksize and listen to differences - it will vary from snappy attack envelope (low buffersize) to mellow slower attack envelope with high buffersize.

akademie

!! NOTE: Not to confuse with envelopes of synth plugins in VST (AU, etc.) format. Only JS Effects are affected by the buffersize!

Last edited by akademie; 01-15-2019 at 02:50 AM.
akademie is offline   Reply With Quote
Old 01-15-2019, 04:14 AM   #50
ChristopherT
Human being with feelings
 
Join Date: Apr 2017
Location: South
Posts: 401
Default

OK thanks,
I understand the playback delay, and that is not really an issue, but I had no idea the visuals would be delayed,
nor the automation as accurate. (glad I asked)
ChristopherT is offline   Reply With Quote
Old 01-15-2019, 04:29 AM   #51
Coachz
Human being with feelings
 
Coachz's Avatar
 
Join Date: Oct 2010
Location: Charleston, SC USA
Posts: 5,778
Default

Why would the automation parameters not be accurate anymore at a higher buffer size? I thought everything just got delayed at startup
Coachz is online now   Reply With Quote
Old 01-15-2019, 05:13 AM   #52
akademie
Human being with feelings
 
Join Date: Mar 2007
Posts: 363
Default

Quote:
Originally Posted by Coachz View Post
Why would the automation parameters not be accurate anymore at a higher buffer size? I thought everything just got delayed at startup
Hmmm, I am not sure, but could it be because this processes are happening in sample blocks? (So then it won't be possible to make extra fast change in parameter when another "update" is planned to near sample block, not individual sample - but there may be some exceptions where "sample accurate" function is featured.
akademie is offline   Reply With Quote
Old 01-15-2019, 05:37 AM   #53
Coachz
Human being with feelings
 
Coachz's Avatar
 
Join Date: Oct 2010
Location: Charleston, SC USA
Posts: 5,778
Default

Larger sample blocks should just mean that it is able to pass larger blocks of audio at a time along with the automation. is there any proof that this is actually happening and that automation is losing its accuracy with higher buffer sizes
Coachz is online now   Reply With Quote
Old 01-15-2019, 07:04 AM   #54
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 23,170
Default

Quote:
but could it be because this processes are happening in sample blocks
This matches what I remember, and also correct on the envelope part.
karbomusic is offline   Reply With Quote
Old 01-15-2019, 07:07 AM   #55
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Germany
Posts: 6,333
Default

There had been a discussion on sample accurate automation in the prerelease forum. Maybe it's implemented now.

-Michael
__________________
www.boa-sorte.de
mschnell is offline   Reply With Quote
Old 01-15-2019, 07:08 AM   #56
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 23,170
Default

Quote:
Originally Posted by Coachz View Post
Larger sample blocks should just mean that it is able to pass larger blocks of audio at a time along with the automation. is there any proof that this is actually happening and that automation is losing its accuracy with higher buffer sizes
I'm 99% positive automation envelope's processing are tied to the buffer size. If you look hard enough you'll find a thread from maybe ~7 years ago where Airon reminded me of this fact.
karbomusic is offline   Reply With Quote
Old 01-15-2019, 07:09 AM   #57
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 23,170
Default

Quote:
Originally Posted by mschnell View Post
There had been a discussion on sample accurate automation in the prerelease forum. Maybe it's implemented now.

-Michael
That would be cool as it would make mixing at low latencies (from a studio perspective) even less practical.
karbomusic is offline   Reply With Quote
Old 01-15-2019, 07:11 AM   #58
akademie
Human being with feelings
 
Join Date: Mar 2007
Posts: 363
Default

Well, Coachz, you can test it for yourself.
Make an automation that will abrupt change some parameter (square type) at some measure or beat. Play at various buffer sizes and you will hear that at buffer 128 samples and lower the change will immediate while at buffers 2048 samples and higher that change will be slow. I did quickly verified it now, but I am at work now and cannot supply any reasonable project file at the moment.
Still, for many mixing automation it may be ok, but as precise sound creation tool it is night and day difference.
akademie 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 06:09 PM.


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