Go Back   Cockos Incorporated Forums > Projects > Deprecated REAPER issue tracker > Feature Request

Project preload/buffering Issue Tools
issueid=1862 01-12-2010 01:55 AM
Project preload/buffering
Functionality issue for larger projects

Demanding a function to preload project's media.

Large projects stutter on first playback.
Reaper's transport flashes red.

Stem increases project's media weight.

Here is a test project that demonstrate this behavior and which also allows you to properly gauge your computer's actual limit using Reaper.
Issue Details
Issue Type Feature Request
Project Deprecated REAPER issue tracker
Category Stability
Status Suggested
Priority 1 - Highest
Suggested Version 3.161
Implemented Version (none)
Users who would use this feature 18
Users who would not use this feature 0
Assigned Users (none)
Tags (none)

01-12-2010 04:14 AM
Super Moderator (no feelings)
From the project notes:

============= Buffering test =======================

1: select all tracks

2: Right click on a track and use the action "Render selected tracks to stem tracks (and mute originals)"

3: Play back the project (Should play fine)

4: Save the project as BUFFERING_test 02

5: Restart your computer (not just reaper)

6: Open BUFFERING_test 02.rpp

7: Playback (You will get stuttering and a red flashing in the transport)
If it doesn't, it means your computer is more powerfull than mine (go to step 10)

8: Let it play to the end despite the stuttering

9: Playback again (Should play fine)

************************************************** *

10. Select all tracks and unmute them.

11. Go back to step 2

************************************************** *
01-12-2010 05:35 AM
Super Moderator (no feelings)
The report is phrased more like a FR. For a bug report I'm missing some information about resource usage while the buffering issues occur (CPU/RAM), how many tracks are needed on your specific system to cause stutter, what system that is and what makes you think this is not specific to your configuration. Your preferences may be set up wrong. Is there resampling involved (this may max out your CPU on 60 tracks so there's not enough room for the load caused by HDD transfer)? Your HDD may be faulty/slow/affected by the Win PIO trap whereby this issue seems to sound like a problem with your HDD sub-system in general. This investigation should ideally happen in the forums btw.

It seems I can't repro the issue on my moderate C2D laptop with single internal HDD. The problem at step 7 doesn't show up and when I repeat the process (~170 tracks), I end up at the physical limits of my HDD (and a hang issue I have to investigate later).
01-12-2010 06:36 AM
Moving to feature requests.
01-12-2010 09:41 AM
Hi :)

I understand how this may look like a FR... And yes, maybe it is one.
But please have a good look at it as I believe it is closer to a flaw within Reaper than to a FR.

All that is needed is a way for Reaper to store the project's media to RAM prior to the very first playback of a session(computer restarted/RAM flushed).
Reaper is already buffering the media to RAM but it is doing it as the project plays the first time.
So, any pre-buffering or playback simulation shall do the trick.

This ''feature'' is part of many if not almost all DAWS.
Some have a shortcut for it, some do it at project loading and some (very annoying) are doing it everytime you push play.

In the end, what that means is that once you have too much CPU load, you'll want to stem your CPU-demanding tracks...It will give you back some of your CPU power to progress on your project and mixing but, you are increasing you projects media weight. So, it is only a matter of time before you experience this issue on bigger projects.
I confirmed this behavior on 8 computers out of 8 so far (all PCs).
I have tried all the system tweaks I was suggested or could think of but nothing heals it.
The only way around it at the moment is to let the project play through despite the sound stuttering (go grab a coffee) and then you are good to go.
Looks a little unprofessional if you've got clients in the studio IMHO.

So, if this is a FR, please make it a priority one.
01-12-2010 10:50 AM
Human being with feelings
Confirmed here. I had to double track count on this machine to get it to lock up.

It's a mixture of many things, hardware limitations mainly. Preloading for large projects can only go so far but something like this would help people with less capable machines.

The main thing I would add to this FR would be to add a preloading bar showing the amount of preload. With larger projects I knew it was preloading but I didn't know how much. Sometimes A project would play flawlessly then on 2nd play it would crunch and I would have to restart reaper just to get it to play back again.
01-12-2010 04:37 PM
Human being with feelings
i do not see a need for a preload feature here. i see a bug. the issue i think is:

1. too many tracks causes stuttering, (which is normal).

2. when track count exceeds the streaming capacity and then track count is reduced:
the machine acts like it still needs to play the removed tracks. i found this was
the case when i reduced track count to one track (reaper still stuttered until i
restarted reaper).

2. seems to be the bug.
but i don't see any reason to think that pre-loading would help.
rather, it seems like reaper is still attempting to load and stream
tracks/items which have been deleted from a project.

jeff dinces
01-12-2010 05:49 PM
Super Moderator (no feelings)
Ok I tested some more:

- There's definitely no difference between "project playing first time after reboot" and "second run" on this computer.

The limit where short dropouts begin to occur here is around 70 tracks, but this is not depending on a reboot or playing the project a second time. At this track count, sequential read figures of HDDs are not that important anymore, access times and cache sizes limit things then and the actual throughput figures repeatedly getting close to their sequential read limits here tell me that the HDD must be at its maximum possible performance.

If you experience a difference, this may happen in the various caching instances of your system rather than Reaper's buffering. The chipset, its drivers, type of HDD and/or something that is simply disturbing playback (something like DPCs or something else that affects the CPU) while the cache(s) is (are) being filled may be responsible for that. I remember seeing reports about Intel Storage drivers not playing as nice as they should etc...

I don't think "project preload" is as easy as it sounds. Loading as many tracks as possible into RAM will put a huge load on your memory sub-system and many elementary functions in a host software rely on maximum possible memory throughput ("L2 cache doubling from 1 to 2 MB will give you 25% more room for plugins"). Sharing the available bandwidth intensively with media streaming (beyond the extent the OS does this anyway) won't possibly give you much improvement if I cooked this up correctly.

Originally Posted by cerberus
2. when track count exceeds the streaming capacity and then track count is reduced:
the machine acts like it still needs to play the removed tracks. i found this was
the case when i reduced track count to one track (reaper still stuttered until i
restarted reaper).
- I can't reproduce this either. Deleting excess tracks cures everything immediately. This is different when the excess load was huge (120+ tracks), then it takes a while until the system becoms responsive again, I suspect Win flushing and resizing cache(s) and maybe some swap file housekeeping causes this.
01-12-2010 06:01 PM
Ok, Maybe I got the ''why'' wrong but I am 100% positive about my observations being :

First playback fails on big projects but second playback is fine.
This is directly related to media weight. (Always triggered by stems)

Whatever happens during this first playback allowing the second one to play fine should be done prior to first playback.

01-12-2010 10:48 PM
Human being with feelings
I had exactly the same problem in the past, as soon as I exceeded a certain number of tracks.
That can really become rather embarrassing... :(
01-13-2010 01:26 PM
Super Moderator (no feelings)

Issue Tools
Subscribe to this issue

All times are GMT -7. The time now is 11:32 AM.

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