Old 04-04-2011, 08:18 AM   #1
effitall
Human being with feelings
 
Join Date: Jan 2010
Posts: 282
Default 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?
effitall is offline   Reply With Quote
Old 04-04-2011, 08:20 AM   #2
junioreq
Human being with feelings
 
junioreq's Avatar
 
Join Date: Aug 2008
Location: Buffalo NY
Posts: 1,091
Default

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.
junioreq is offline   Reply With Quote
Old 04-04-2011, 08:28 AM   #3
effitall
Human being with feelings
 
Join Date: Jan 2010
Posts: 282
Default

Quote:
Sometimes also, it says "buffering" and wont play, i have to keep pushing
You're not by chance using ReaInsert are you?
effitall is offline   Reply With Quote
Old 04-04-2011, 08:35 AM   #4
Ollie
Super Moderator (no feelings)
 
Ollie's Avatar
 
Join Date: Dec 2007
Location: On or near a dike
Posts: 9,834
Default

Quote:
Originally Posted by effitall View Post
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 View Post
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?
Ollie is offline   Reply With Quote
Old 04-04-2011, 08:43 AM   #5
effitall
Human being with feelings
 
Join Date: Jan 2010
Posts: 282
Default

- 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.
effitall is offline   Reply With Quote
Old 04-04-2011, 08:54 AM   #6
Ollie
Super Moderator (no feelings)
 
Ollie's Avatar
 
Join Date: Dec 2007
Location: On or near a dike
Posts: 9,834
Default

Quote:
Originally Posted by effitall View Post
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.
Ollie is offline   Reply With Quote
Old 04-04-2011, 08:58 AM   #7
effitall
Human being with feelings
 
Join Date: Jan 2010
Posts: 282
Default

- 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.
effitall is offline   Reply With Quote
Old 04-04-2011, 09:10 AM   #8
Ollie
Super Moderator (no feelings)
 
Ollie's Avatar
 
Join Date: Dec 2007
Location: On or near a dike
Posts: 9,834
Default

- 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?
Ollie is offline   Reply With Quote
Old 04-04-2011, 09:18 AM   #9
nofish
Human being with feelings
 
nofish's Avatar
 
Join Date: Oct 2007
Location: home is where the heart is
Posts: 12,096
Default

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
nofish is offline   Reply With Quote
Old 04-04-2011, 01:15 PM   #10
effitall
Human being with feelings
 
Join Date: Jan 2010
Posts: 282
Default

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.
effitall is offline   Reply With Quote
Old 04-04-2011, 01:26 PM   #11
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 29,260
Default

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.
karbomusic is offline   Reply With Quote
Old 04-04-2011, 01:38 PM   #12
effitall
Human being with feelings
 
Join Date: Jan 2010
Posts: 282
Default

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?
effitall is offline   Reply With Quote
Old 04-04-2011, 01:47 PM   #13
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 29,260
Default

Quote:
Originally Posted by effitall View Post
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.
karbomusic is offline   Reply With Quote
Old 04-04-2011, 03:14 PM   #14
Ollie
Super Moderator (no feelings)
 
Ollie's Avatar
 
Join Date: Dec 2007
Location: On or near a dike
Posts: 9,834
Default

Quote:
Originally Posted by effitall View Post
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 View Post
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 View Post
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
Ollie is offline   Reply With Quote
Old 04-04-2011, 04:34 PM   #15
effitall
Human being with feelings
 
Join Date: Jan 2010
Posts: 282
Default

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.
effitall is offline   Reply With Quote
Old 04-04-2011, 05:02 PM   #16
nfpotter
Human being with feelings
 
Join Date: Feb 2009
Location: Portland, OR, USA
Posts: 1,057
Default

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
nfpotter is offline   Reply With Quote
Old 04-04-2011, 05:07 PM   #17
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 29,260
Default

Quote:
Originally Posted by effitall View Post
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.
karbomusic is offline   Reply With Quote
Old 04-05-2011, 07:08 AM   #18
effitall
Human being with feelings
 
Join Date: Jan 2010
Posts: 282
Default

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.
effitall is offline   Reply With Quote
Old 04-05-2011, 07:39 AM   #19
Dstruct
Human being with feelings
 
Join Date: Jul 2006
Posts: 12,480
Default

It's a known bug: http://forum.cockos.com/project.php?issueid=1862 (although it's posted as Feature Request)
Dstruct is offline   Reply With Quote
Old 04-05-2011, 08:28 AM   #20
phonofranz
Human being with feelings
 
phonofranz's Avatar
 
Join Date: Jan 2008
Location: Padova, Italy
Posts: 471
Default

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.
__________________
Franz[.]Suono - Studio di Registrazione
http://www.franzsuono.com https://www.facebook.com/franzpuntosuono
phonofranz is offline   Reply With Quote
Old 04-05-2011, 10:17 AM   #21
effitall
Human being with feelings
 
Join Date: Jan 2010
Posts: 282
Default

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.
effitall 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 12:42 AM.


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