What causes playback to drop or pause constantly?

[davidicus]

I haven't had this problem before. It started a few months ago, and is making it incredibly frustrating to record or mix.
I have a 7th gen i5 laptop. Even if I use no VSTs or effects, I'll get a periodic dropout. It does seem to get worse as I add effects.
I've tried:

• swapping my audio interface (which does seem to help--the worse problems might be with generic ASIO drivers?),

• killing background processes (there are few, since this machine is lean and dedicated to music production),

• ensuring there's as much memory and drive space as I can muster (16GB RAM, 200+GB free on SSD),

• updating Windows and all my drivers

It seems to love waiting for a particularly good take and then dropping momentarily in the middle of it, and it's killing me.

[Loque]

Power saving mode? Use highest performance.

[guitfnky]

hard to say without a better sense of what your setup is like. if you haven't already, I'd google some guides for PC settings to use for audio production. other than that, make sure your buffer settings aren't aggressively low (setting a 64 or 96 sample buffer could be too low, depending on your system).

[davidicus]

I hadn't checked power/performance--thanks!
My buffer's actually uncomfortably high. When it's lower, it crackles nasty. Hm.

[Bjørn Felle]

16GB might not be enough. I have found that even having just a few devices in the rack can cause issues, and looking in the system activity monitor shows that memory is low at these times. Often a reboot sorts it for a bit.

[guitfnky]

I highly doubt only 16 gigs of RAM is what’s causing your issues (unless it’s installed incorrectly [mismatched sticks/in the wrong slots]). I’ve never had issues using 8-16 GB of RAM—well, no issues caused by the RAM, at least.

[diminished]

A few months ago my CPU heat sink wasn't installed properly. My CPU throttled itself so it didn't die a heat death. Windows brought it up to 70°C when idling, and Reason, well..

I used the open source tool OpenHardwareMonitor to check the temp: https://openhardwaremonitor.org/

[antic604]

I highly doubt only 16 gigs of RAM is what’s causing your issues (unless it’s installed incorrectly [mismatched sticks/in the wrong slots]). I’ve never had issues using 8-16 GB of RAM—well, no issues caused by the RAM, at least.

Yeah, I've no idea where this "add more RAM if DAW is stuttering" advice came from?! Unless they're using tons of audio libraries like Kontakt or long audio files (like band tracking), then you'll rarely need more than 8-16GB. 9 times out of 10 it's the CPU issue.

[Raveshaper]

I haven't had this problem before. It started a few months ago, and is making it incredibly frustrating to record or mix.
I have a 7th gen i5 laptop. Even if I use no VSTs or effects, I'll get a periodic dropout. It does seem to get worse as I add effects.
I've tried:

• swapping my audio interface (which does seem to help--the worse problems might be with generic ASIO drivers?),

• killing background processes (there are few, since this machine is lean and dedicated to music production),

• ensuring there's as much memory and drive space as I can muster (16GB RAM, 200+GB free on SSD),

• updating Windows and all my drivers

It seems to love waiting for a particularly good take and then dropping momentarily in the middle of it, and it's killing me.

I would say that if these or similar projects are critical, use something more mature to record, and possibly mix as well.

Reason does not appear to have parallelism. Possibly the gorilla engine in 10.4 has changed that but I don't know. Without parallelism, things are iterative and can fall victim to "blocking code", meaning code that can't run until the previous code has finished executing.

This I think is the heart of a lot of these problems with dropouts. The more code that's trying to run in sequence, the less time there is for the processor to complete everything that's running. Eventually the CPU stalls out because the amount of things to execute exceeds the amount of time it can complete those tasks in.

Reason effectively allocates the maximum amount of memory for a given device. It doesn't take into account whether you aren't using most of the behavior that would require that memory, it just reserves as much memory as would be required to utilize every single bell and whistle of that device at once. That makes sense to have it on hand in the event that you want to make use of any of those things, but it does this for ever instance of device as well -- even if they're the same kind of device.

This means that memory consumption is based more or less on running devices inside of discreet "containers" that are internally recognized as distinct from one another. The contrast to that would be pooling resources in one place within memory, then recognizing devices as instances of a given type that can then tap into that one place in memory to calculate whatever they need to do at scale.

Further, these containerized devices that don't optimize memory are loaded into a "has many" linked list style graph that can also have loops in it. Meaning performance gets hit again by having to mitigate the potential for endless stack frames of recursion in some cases (like audio feedback in the cables).

The cherry on top is that, without being specific, resources are loaded in that consume memory but are never used. That's a whole rabbit hole of its own.

To sum it all up, even though I don't have x-ray vision to see the entirety of these glaring problems with unabridged clarity, I wouldn't recommend trying to make Reason suit your professional needs. The core of the architecture is unoptimized to a legendary level -- even now.

Fun creative play space, not professional workspace.

[tobypearce]

Does it do it more, or less when the rack is open and/or vst instruments are open? In other words, when there's more going on with the graphics?

[davidicus]

A few months ago my CPU heat sink wasn't installed properly. My CPU throttled itself so it didn't die a heat death. Windows brought it up to 70°C when idling, and Reason, well..

I used the open source tool OpenHardwareMonitor to check the temp: https://openhardwaremonitor.org/

smart and lucky...glad you tracked it down. thank you, i'll check too

[davidicus]

To sum it all up, even though I don't have x-ray vision to see the entirety of these glaring problems with unabridged clarity, I wouldn't recommend trying to make Reason suit your professional needs. The core of the architecture is unoptimized to a legendary level -- even now.

Fun creative play space, not professional workspace.

this info is really helpful. I use a template that now worries me. I'm going to start from absolute scratch and see what I can determine. thanks a bunch!

also makes me consider turning up the heat on evaluation of other DAWs.

[Raveshaper]

this info is really helpful. I use a template that now worries me. I'm going to start from absolute scratch and see what I can determine. thanks a bunch!

also makes me consider turning up the heat on evaluation of other DAWs.

I wish I could offer a solution but these problems run rather deep. And you won't struggle as much using something better suited to the task.

[Loque]

I haven't had this problem before. It started a few months ago, and is making it incredibly frustrating to record or mix.
I have a 7th gen i5 laptop. Even if I use no VSTs or effects, I'll get a periodic dropout. It does seem to get worse as I add effects.
I've tried:

• swapping my audio interface (which does seem to help--the worse problems might be with generic ASIO drivers?),

• killing background processes (there are few, since this machine is lean and dedicated to music production),

• ensuring there's as much memory and drive space as I can muster (16GB RAM, 200+GB free on SSD),

• updating Windows and all my drivers

It seems to love waiting for a particularly good take and then dropping momentarily in the middle of it, and it's killing me.

I would say that if these or similar projects are critical, use something more mature to record, and possibly mix as well.

Reason does not appear to have parallelism. Possibly the gorilla engine in 10.4 has changed that but I don't know. Without parallelism, things are iterative and can fall victim to "blocking code", meaning code that can't run until the previous code has finished executing.

This I think is the heart of a lot of these problems with dropouts. The more code that's trying to run in sequence, the less time there is for the processor to complete everything that's running. Eventually the CPU stalls out because the amount of things to execute exceeds the amount of time it can complete those tasks in.

Reason effectively allocates the maximum amount of memory for a given device. It doesn't take into account whether you aren't using most of the behavior that would require that memory, it just reserves as much memory as would be required to utilize every single bell and whistle of that device at once. That makes sense to have it on hand in the event that you want to make use of any of those things, but it does this for ever instance of device as well -- even if they're the same kind of device.

This means that memory consumption is based more or less on running devices inside of discreet "containers" that are internally recognized as distinct from one another. The contrast to that would be pooling resources in one place within memory, then recognizing devices as instances of a given type that can then tap into that one place in memory to calculate whatever they need to do at scale.

Further, these containerized devices that don't optimize memory are loaded into a "has many" linked list style graph that can also have loops in it. Meaning performance gets hit again by having to mitigate the potential for endless stack frames of recursion in some cases (like audio feedback in the cables).

The cherry on top is that, without being specific, resources are loaded in that consume memory but are never used. That's a whole rabbit hole of its own.

To sum it all up, even though I don't have x-ray vision to see the entirety of these glaring problems with unabridged clarity, I wouldn't recommend trying to make Reason suit your professional needs. The core of the architecture is unoptimized to a legendary level -- even now.

Fun creative play space, not professional workspace.

Lot of guessing and vague argumentation without evidence or knowledge. Tbh, this is a lot of bs. Sorry for the harsh words.

[Raveshaper]

I'm not going to get into this any deeper because, legally, I literally can't.

[davidicus]

I'm not going to get into this any deeper because, legally, I literally can't.

Well, I believe it. It explains a lot. Thanks for spelling it out.
I'm taking stock of which rack devices I'm attached to, so I can figure out whether to buy Reason one last time, or find replacement VSTs instead. Either way, It's clear I need to bite the bullet into a new DAW.

[Steedus]

I’m sure people will say this is bollocks, but for me, I’ve always has this kind of issue since upgrading from version 6 to 10. My original PC used to be flawless with older versions of Reason up to 6.5, but after upgrading to 10 I started to notice glitches in playback and spikes in the DSP meter no matter what my settings were. I adde more RAM, bought a new audio interface to try and fix things I thought might be the cause. Nothing helped.

I’ve since “upgraded” to a 2018 MacBook Pro with 16GB and the 2nd fastest i7 6-core CPU, and ... it’s exactly the same. I’ve just had to learn to live with it. And though Reason me me is just a hobby, it’s still frustrating as heck sometimes.

[diminished]

Quick question. Have you guys disabled hyperthreading already?

[davidicus]

Quick question. Have you guys disabled hyperthreading already?

I haven't tried it--can that really help? What about multi-core?

[diminished]

Quick question. Have you guys disabled hyperthreading already?

I haven't tried it--can that really help? What about multi-core?

In general, keep that.