|
|
|
04-04-2011, 08:18 AM
|
#1
|
Human being with feelings
Join Date: Jan 2010
Posts: 282
|
Reapers disk access/initial playback
I've got an issue with Reaper and "bursty" disk access. Mostly Reaper will playback a song fine, however in spots it will "stutter" and the "disk read" in Perfomance view will drop and then shoot up high.
What I can't really come up with an answer for is why Reaper will have this issue in the first or second playback, but after that...It plays the song back with no problem. No "bursty" numbers in Performance view.
This happens whether I'm using a local disk on the system or a NAS drive.
CPU usage never goes over 50%, Initial playback disk access varies from 2MB/s to 8MB/s, later playbacks vary from 4.6MB/s to 5.3MB/s.
This happens consistently with every song. Open the project, playback, stutter, sputt, playback, stutter-sput, playback, stutter. Songs ends, playback from beginning and it plays back flawlessly. Close project, open another project, repeat the above scenario.
Any insight?
|
|
|
04-04-2011, 08:20 AM
|
#2
|
Human being with feelings
Join Date: Aug 2008
Location: Buffalo NY
Posts: 1,091
|
I have this problem too, i actually have to push play let it stutter(bad). Push stop. Push play, let it stutter(a little less). Push play... and finally after a couple times it will play... Annoying, guess its something with my system....
Can't help, would like to know also... Sometimes also, it says "buffering" and wont play, i have to keep pushing play/stopping...
~Rob.
|
|
|
04-04-2011, 08:28 AM
|
#3
|
Human being with feelings
Join Date: Jan 2010
Posts: 282
|
Quote:
Sometimes also, it says "buffering" and wont play, i have to keep pushing
|
You're not by chance using ReaInsert are you?
|
|
|
04-04-2011, 08:35 AM
|
#4
|
Super Moderator (no feelings)
Join Date: Dec 2007
Location: On or near a dike
Posts: 9,834
|
Quote:
Originally Posted by effitall
What I can't really come up with an answer for is why Reaper will have this issue in the first or second playback, but after that...It plays the song back with no problem. No "bursty" numbers in Performance view.
|
This sounds like there is a problem with disk access...at times. Only when the entire project media is in the various caches, the problem stops. But:
Quote:
Originally Posted by effitall
This happens whether I'm using a local disk on the system or a NAS drive.
|
That contradicts the idea above a bit, except the NAS drive is actually the problem, maybe your NIC is causing this.
- Does that also happen when you disable the NIC in Device Manager?
- What is your OS?
- When did that start?
- Did you run the DPC checker?
|
|
|
04-04-2011, 08:43 AM
|
#5
|
Human being with feelings
Join Date: Jan 2010
Posts: 282
|
- Does that also happen when you disable the NIC in Device Manager?
The NAS is a new experiment...It's a SNAP Server 520 with a direct Gigabit connection to my audio system. I only tried the NAS recently (Like today) because this issue has come up along with my "rendering" issue referenced in another thread. I have not disabled the network interfaces on my system, but then...This isn't a new system either. I am pushing it harder than I used to with a move from 48k to 96k.
- What is your OS?
Windows XP64
- When did that start?
Since I've gotten heavily into 96k tracking/mixing. Which does point to a resource issue. However...I can't find the problem.
- Did you run the DPC checker?
DPClat runs green. Always.
|
|
|
04-04-2011, 08:54 AM
|
#6
|
Super Moderator (no feelings)
Join Date: Dec 2007
Location: On or near a dike
Posts: 9,834
|
Quote:
Originally Posted by effitall
Since I've gotten heavily into 96k tracking/mixing. Which does point to a resource issue. However...I can't find the problem.
|
- Did you convert/rerecord all media to 96kHz? Resampling on-the-fly is costly.
- Some plug-ins don't like high sample rates very much, maybe only a common plug-in in all projects is initially causing the problem? This could also relate to your "render" problem
Both questions could probably be answerered by creating a project with lots of 96k tracks and no plug-ins.
- Do all CPU measurements in Task Manager, not REAPER in order to get the overall system load when using REAPER.
|
|
|
04-04-2011, 08:58 AM
|
#7
|
Human being with feelings
Join Date: Jan 2010
Posts: 282
|
- Did you convert/rerecord all media to 96kHz? Resampling on-the-fly is costly.
Yes indeed....All project files are 96k so no resampling is occuring. Keep in mind...This only happens on INITIAL playback. All subsequent playbacks are FLAWLESS.
- Some plug-ins don't like high sample rates very much, maybe only a common plug-in in all projects is initially causing the problem? This could also relate to your "render" problem
Again...For this issue...I don't think this is the problem as the only playback that has an issue is the first or second playback. All subesquent playbacks are fine.
- Do all CPU measurements in Task Manager, not REAPER in order to get the overall system load when using REAPER.
Task manager is actually more in favor of me NOT having a CPU issue than Reaper as it's reporting lower than Reaper is. However...In regards to my other issue with rendering, Reaper was superior in showing me that I have a spike in "RT CPU" which didn't show up in Perfmon or Taskman.
|
|
|
04-04-2011, 09:10 AM
|
#8
|
Super Moderator (no feelings)
Join Date: Dec 2007
Location: On or near a dike
Posts: 9,834
|
- Did you migrate an old reaper.ini from the past by chance or did you reset REAPER to factory defaults to test if that makes a difference?
- Do you have "Optimize buffering for low latency..." still checked in Options-Preferences->Audio->Buffering?
- Does changing the disk access mode to "Asynchronous unbuffered" in Options-Preferences->Audio->Buffering-"Advanced disk I/O options" change anything?
|
|
|
04-04-2011, 09:18 AM
|
#9
|
Human being with feelings
Join Date: Oct 2007
Location: home is where the heart is
Posts: 12,096
|
I get this behaviour too on bigger projects.
Initial playback gives stuttering, then after playing two or three times it's fine.
Link to an older thread about this (where some people confirmed this behaviour):
http://forum.cockos.com/showthread.php?p=435321
|
|
|
04-04-2011, 01:15 PM
|
#10
|
Human being with feelings
Join Date: Jan 2010
Posts: 282
|
I had previously ruled out a driver latency issue because when I'd run DPClat and have a problem..DPClat never moved. However I do have some random spikes in DPClat (up to 16000+ sometimes). For PD, I've disabled all network cards, com ports, and USB ports. There's really nothing left to turn off.
Something to note...The DPClat spikes do not correlate to playback issues.
What does correlate is an increase in RT CPU. A search yields:
"The RT ("Real Time") CPU meter measures the amount of CPU time used by the audio thread servicing the sound device. Since it's measuring a single thread, it reflects only the CPU time used by one core, and gives you an indication of how much leeway you have in processing. If you have anticipative FX enabled (and few tracks record armed), RT CPU will generally be pretty low, as most things should be done asynchronously, allowing the realtime thread to quickly put things together. "
There's also a correlation to disk access. I notice when there's a playback issue, RT CPU spikes, disk read drops and then shoots way up, then returns to normal.
This occurs whether I'm using an internal disk or a NAS drive. Actually..the NAS drive performs better than the internal drive.
As for your questions Ollie...
- Did you migrate an old reaper.ini from the past by chance or did you reset REAPER to factory defaults to test if that makes a difference?
This current system is the only one I've ever used for Reaper. I loaded it at v3.01 I believe and have upgraded each version up to 3.75. I could reset the INI...
- Do you have "Optimize buffering for low latency..." still checked in Options-Preferences->Audio->Buffering?
Yes
- Does changing the disk access mode to "Asynchronous unbuffered" in Options-Preferences->Audio->Buffering-"Advanced disk I/O options" change anything?
Not much...If anything it's a little worse.
|
|
|
04-04-2011, 01:26 PM
|
#11
|
Human being with feelings
Join Date: May 2009
Posts: 29,260
|
Quote:
What I can't really come up with an answer for is why Reaper will have this issue in the first or second playback, but after that...It plays the song back with no problem. No "bursty" numbers in Performance view.
|
Because the first time you press play from a particular playback position, Reaper preloads/buffers from that position + n seconds forward into memory and keeps them there. Everytime you move the cursor to a postition that does not encompass something that has been played before, it has to preload that new section. You can select several different playback positions and mark them with markers while testing this and you should notice that all of those exact positions will now always play without delay after the initial buffering.
Once it is preloaded, returning to that spot usually results in instant playback because it is in memory. So, if the buffer settings are at their default it shouldn't pop or click, you'll just see a short delay or spike before playback starts. The more tracks, the longer the delay. Buffer too low likely would result in pops and clicks. Granted, if the disks are slow on their own you'll see more problems regardless but this particular behavior is good to know about. I think it is a good thing by the way.
I tested this pretty deeply last year by measuring disk activity as Reaper loaded data directly from disk. There is a thread here of that testing somewhere. IIRC you can also watch Reaper's memory allocations and actually see the memory grow to accomodate the chunks of preload data that are being loaded into process memory.
Karbo
__________________
Music is what feelings sound like.
Last edited by karbomusic; 04-04-2011 at 01:32 PM.
|
|
|
04-04-2011, 01:38 PM
|
#12
|
Human being with feelings
Join Date: Jan 2010
Posts: 282
|
Hey Karbo,
I had read that thread earlier today and paid special attention to Reaper's memory foot-print. I can honestly say that it never changed no matter how many time I stopped, jumped, started, jumped, stopped etc.
Perhaps some behavior has changed over the past year because your assertions don't seem to hold true now. Do you have a more specific test?
|
|
|
04-04-2011, 01:47 PM
|
#13
|
Human being with feelings
Join Date: May 2009
Posts: 29,260
|
Quote:
Originally Posted by effitall
Hey Karbo,
I had read that thread earlier today and paid special attention to Reaper's memory foot-print. I can honestly say that it never changed no matter how many time I stopped, jumped, started, jumped, stopped etc.
Perhaps some behavior has changed over the past year because your assertions don't seem to hold true now. Do you have a more specific test?
|
Where are you looking at the "memory footprint"? And this might not be the issue you are seeing....
This quick specific test is to show the behavior. However, this all goes out the window if you have been mucking around with the default disk settings in reaper.
1. Load up enough tracks so that when you click play it takes about 1/2 second before it audio starts. Mark that position.
2. Go do a new section at least 20-30 seconds away from the previous one. Mark it first then click play, it should have the same delay.
3. Move the cursor back to the position in step 1 (Marker 1). Click play, it should play back instantly. Same if you go back to Marker 2.
4. Go to a complete new section 20-30 seconds away from the previous two sections. Click play, you should see the delay again.
I leave all buffer and disk settings at default, always have or anomalies tend to pop up. If the behavior has changed, I'll test it later but I don't suspect it would have, its pretty basic.
Karbo
__________________
Music is what feelings sound like.
|
|
|
04-04-2011, 03:14 PM
|
#14
|
Super Moderator (no feelings)
Join Date: Dec 2007
Location: On or near a dike
Posts: 9,834
|
Quote:
Originally Posted by effitall
There's also a correlation to disk access. I notice when there's a playback issue, RT CPU spikes, disk read drops and then shoots way up, then returns to normal.
This occurs whether I'm using an internal disk or a NAS drive. Actually..the NAS drive performs better than the internal drive.
|
The correlation between the CPU spike and the dropout in disk read is very interesting. Since you're on XP, only RATTv3 can help you diagnose this.
But if the problem reliably clears up after all media was cached and your NAS seems to work better, a simple "PIO mode" issue comes into mind. When Windows repeatedly counts disk errors (sometimes caused by a series of crashes), it throttles back until your disk runs in the slowest "PIO" mode, with every disk transfer costing much CPU. Check if the transfer mode in Device Manager is still "UDMA-x" (what is x on your disk?).
Quote:
Originally Posted by effitall
I could reset the INI...
|
Please backup your user folder (or at least your reaper.ini) and try that, just to rule out bad prefs settings. I migrated my ini since v2 but in the course of heavy testing of stuff it actually did break once and needed a reset.
Quote:
Originally Posted by effitall
Not much...If anything it's a little worse.
|
That's "expected", IIRC only a few specific disks work better unbuffered (but I may have confused that).
Have we ruled out plug-ins completely yet? They can affect buffering big time and e.g. some wonky SE plug-ins can cause random mayhem in completely unrelated parts of the system out of the blue. "Denormals" can cause CPU activity on idling plug-in instances and samplers have their own disk streaming tasks... So does it happen without (or only stock) plug-ins?
Last edited by Ollie; 04-04-2011 at 03:22 PM.
Reason: Yes
|
|
|
04-04-2011, 04:34 PM
|
#15
|
Human being with feelings
Join Date: Jan 2010
Posts: 282
|
Quote:
The correlation between the CPU spike and the dropout in disk read is very interesting. Since you're on XP, only RATTv3 can help you diagnose this.
|
Well..I'm a little eff'd here because RATTV3 doesn't work on 64bit Winblows. The only other tools I've seen only work on Vista or later. :/
Quote:
But if the problem reliably clears up after all media was cached and your NAS seems to work better, a simple "PIO mode" issue comes into mind. When Windows repeatedly counts disk errors (sometimes caused by a series of crashes), it throttles back until your disk runs in the slowest "PIO" mode, with every disk transfer costing much CPU. Check if the transfer mode in Device Manager is still "UDMA-x" (what is x on your disk?).
|
I just ran some benchmarks on the drives. My current "audio" drive clocks in at 80MB/s sustained transfer rate. I doubt it's a PIO mode issue.
For Karbo...I was able to duplicate the instantaneous start of "cached" audio vs. the delayed start of un-cached audio. Confirmed.
|
|
|
04-04-2011, 05:02 PM
|
#16
|
Human being with feelings
Join Date: Feb 2009
Location: Portland, OR, USA
Posts: 1,057
|
I've had this exact problem for a long time now. Never have figured it out, and I've tried. Now, for bigger projects, I just let it play through once and go have a smoke, and then it's usually fine. Shouldn't have to, though. None of my other DAW's do it....
__________________
"A fly was very close to being called a land, 'cause that's what they do half the time."
-Mitch Hedberg
|
|
|
04-04-2011, 05:07 PM
|
#17
|
Human being with feelings
Join Date: May 2009
Posts: 29,260
|
Quote:
Originally Posted by effitall
Well..I'm a little eff'd here because RATTV3 doesn't work on 64bit Winblows.
|
Good news = XPERF will do properly and much more.
Bad news = Output isn't a cakewalk to interpret.
If I could ever get around to using it with Reaper and dig in, I could get some good instructions going on. I have this whole process laid out in my brain on how to properly and definitively diagnose perf issues in reaper using perfmon/xperf and a couple other tools but time is little.
Karbo
__________________
Music is what feelings sound like.
|
|
|
04-05-2011, 07:08 AM
|
#18
|
Human being with feelings
Join Date: Jan 2010
Posts: 282
|
Sooo....I'm going hardcore here...
I've updated all the drivers on my system. I discovered that my OS drive was significantly faster than my audio drive, so I've migrated ALL data to the NAS, wiped the audio drive and moved the OS to it. Once I get that straight I'm going to setup the faster drive for audio and restore a couple of projects and test.
Wheee....All to get a smooth playback and a working render.
|
|
|
04-05-2011, 08:28 AM
|
#20
|
Human being with feelings
Join Date: Jan 2008
Location: Padova, Italy
Posts: 471
|
I'm in the same boat...I'd like to figure this out too. It happens only with a few projects, not necessarily with the highest track count. Cannot really spot a "trend" and it is annoying indeed... every hardware/driver/latency issue is ruled out.
|
|
|
04-05-2011, 10:17 AM
|
#21
|
Human being with feelings
Join Date: Jan 2010
Posts: 282
|
Success...(at least so far) Let's recap...
Problem...Playback stutters when opening a new project for the first time. After that...Playback was smooth. Issue only appeared with more complex projects.
Symptoms...RT CPU spikes and correlated hard disk buffering would drop then spike, then normalize.
Resolution...
Back up all audio data, (in my case change audio drive to fastest I had), format audio drive and restore A project.
I've been in need of cleaning up some audio data in awhile. Keeping your audio drive in tip top shape and only housing "current" projects on it will keep you in good shape. I'm working on a full length right now where after basic tracking, each project folder ballooned to about 12GB of data. Saving the project to a new folder and copying only that projects data will result in a much more compact 2GB or so per project. So life is good at the moment.
Even the render issue I had seems to be gone. I'll post again after I consolidate and restore some other projects.
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 12:42 AM.
|