Hello, I’ve recently started having a strange issue with my system. Everything is working normally, I’ve got several VST loaded up and I’m tracking when all of a sudden the playback gets choppy, the cpu usage surges up and everything chokes to a halt. If I solo 1 channel’s VST it can barely keep up but will be able to play it back somewhat smoothly. It’s like everything in Renoise suddenly takes twice a much cpu. Has anyone come across anything like this before?
Restarting Renoise doesn’t seem to be a solution. Could I be using a memory leaky VST or have bad audio drivers or maybe my sound card is bad? I’m using an Acer Laptop with a Centrino 1.5ghz cpu and Realtek AC97 drivers.
my guess is that it has something to do with ac97 hardware acceleration. i had a similar problem, but i cant remember how i solved it Maybe go to control panel/sounds and audio devices/advanced/perfomance and play around with that slider.
I just tried adjusting the Hardware Acceleration slider. I vaguely recall having to mess with that in the past so I was hoping it would do the trick but no luck yet. The song I’m playing plays ok until a certain point where it just gets bogged down and the cpu usage starts climbing up to 99.9%.
I’m using SpeedSwitchXP and have it set for Max Performance. This has fixed things in the past.
I may just format it and if the issue still persists, start hunting down VST.
That’s quite possible. It doesn’t seem like one specific point necesarilly. It just starts to get complicated and then suddenly you can here it start clipping and then it just builds on itself in 2-3% cpu increments until its choked up at 99.9%. Does a new note following a previous note count as a note-off? Or to get a true note-off do you need to use 2 columns?
Tried it just now, it looks like they both adjust the same setting. Tried each different position but no change in the results, still have the same effect.
I noticed my song uses different VST instruments within the same channel, should that pose any issues? I’ve already started to rearrange the song to give each VST it’s own channel.
I’ve also reinstalled my audio drivers with no effect so I’m thinking this is a VST issue I need to track down. If I mute some of the tracks then the playback improves so there must be some conflicting or problematic VST involved somewhere.
Well I found the culprit! I was using a send track with delay to send to another send track with reverb. Apparently this was causing a lot of build up and eventually choking up Renoise after several leads using the send track started to play. Looks like I better be more careful with how I use send tracks.
Whew glad I didn’t have to go ahead with the format, wasn’t looking forward to reinstalling all my VST.
Okay, you solved your problem for now but just to put in the back of your head:
When a new note starts on the same column, this will sent a note-off to the device. The note-off trigger won’t have a large effect in the following situation however(regardless if a true not-off is being used or triggered by a new note):
If the intrument in the VSTI is being configured with a delay to last very long, the VSTI might go beserk as well in poly mode. (the more voices are allowed simultaneously, the more cpu intense it gets)
Specially if it is a synth vsti.
Well I thought it was fixed but I’m still having problems.
I just repartitioned my drive, installed a new copy of Windows XP, installed Renoise, installed all my VST, loaded a song which I used to be able to work on with no problems and as soon as it starts playing it starts to clip the sound, lag the screen, and the cpu usage goes up until its a 99.9% mess. Songs that previously fully played at 20-30% cpu will play and gather cpu until it hits 99.9% and chokes.
From what I can tell it seems to be a VST problem of some kind since regular sample based RNS files even with heavy DSP usage playback fine. Whats driving me nuts is that tracks that I’ve worked on in the past are now lagging and clipping into a 99.9% cpu mess. Can just having a VST installed and listed in Renoise cause problems? Or some bizarre problem with my soundcard?
I don’t know if it’s any help but here is an example track that will make my comp choke soon after being started (by about row 36 its pausing and clipping). It uses the free EVM Grand Piano VST (available here).
Possible but not sure if that’s it. Once Renoise starts the playback jittery, almost any track using VSTs will start to playback poorly. For example that test2.rns track uses a bunch of instances of just the 1 VST. The test2.rns track gradually incorporates more channels playing notes and at around the 36th row the playback starts to clip and the cpu usage increases by 5 or 6% to 99.9%.
I’m aware of the differences between playing back samples as opposed to VST synthesizers. The issue I’m having trouble figuring out is why lately I’ve been unable to playback tracks which I was able to work on in the past without any problems. test2.rns is a new track that consistently breaks my system. The tracks I’m trying to work on use a variety of vsts (mostly well known, FM7, Pro-53, etc) so aren’t very good test examples.
Is it possible that once Renoise has been overloaded with VSTs that things could get stuck in memory causing Renoise to play even newly loaded tracks (with VST) poorly?
Once Renoise has been overloaded the playback for tracks using VSTs becomes especially lagged and the cpu usage just builds on itself. It’s difficult to explain because it’s such a vague problem and I don’t know where the source is.
I’ve tried isolating a particular VST which is what lead me to test2.rns. Using that 1 VST I’m able to get the effect which is very similar to running out of cpu. I would chalk it up to insufficient cpu accept for the fact that in the past or if it doesn’t glitch I’m able to playback certain tracks smoothly.
I just successfully played back a problem track quite a bit farther than usual. Max cpu usage was around 48-50% for several patterns. At a certain point though the playback cracked and started clipping. Now the the playback doesnt get farther than the first 2 or 3 patterns before the playback clips and the cpu builds on itself into 99.9% oblivion.
Next I closed Renoise and started it up again. This time I loaded a track that I had previously successfully played completely with a max cpu of around 30%. Now this same track starts climbing past 60% cpu as VSTs begin to be used and further until its clipping and at 99.9% cpu.
This is probably the best I can do to describe the chain of events. It’s like once it cracks it takes a reboot to fix it. And even then it can strike right as soon as I load the first track again or after VSTs are gradually introduced. I apologize for being so vague but that’s what’s nuts about it. If its a lack of cpu power then that’s fine but when things back ok for awhile and then it cracks and almost anything with VSTs plays lousy then I’d like to know why.
Restarted computer. Load test2.rns and solo 1 channel for a fully clipless playback at 24% max cpu.
Unmute second channel for a total of 2 channels for full clipless playback at 47% max cpu.
Unmute third channel for a total of 3 channels for a full clipless playback at 70% max cpu.
Unmute fourth channel for a total of 4 channels and playback cracked around row 44. Now, hit the panic button a couple times.
Close and Reopen Renoise. Reload test2.rns and solo 1 channel for a fully clipless playback at 24% max cpu.
Unmuted second channel for a total of 2 channels for full clipless playback at 47% max cpu.
Unmute third channel for a total of 3 channels and playback cracks around 70% cpu. Hit panic button a couple times.
Mute all channels and solo 1 channel for a full clipless playback at 56% max cpu.
Unmute second channel for a total of 2 channels and playback begins to crack at about 23% cpu. Stopped and played again (no panic button), this time full clipless playback at 47% max cpu.
It’s seemingly random. CPU is set to Max Performance with SpeedSwitchXP otherwise I would suspect some kind of cpu mhz switching.
What could be causing this?
My problem is loading a track and the playback sooner or later cracking and clipping. Once this happens then almost any VST chews up much more cpu than usual and almost any track is unplayable.
I’ll try test2.rns with some other vsts and see what the results are. I’m thinking it must be either a bad VST or something strange with my system. Can’t imagine what though since the XP install is fresh and different tracks using different vsts still behave the same way when reaching high levels of cpu usage. Even with latency turned up the 200ms, cpu usage is less at first but eventually the same result.
This is driving me crazy. I have a feeling this problem has to do with my system and not Renoise. It’s difficult to pinpoint if it’s a specific VST because the issue will happen with any track (I’ve tried many) that uses enough cpu. A song will be playing along fine and suddenly (randomly) the playback will repeat about a 1 second chunk, clip and jerk as the cpu usage soars until it cant even playback that 1 second chunk properly. It’s random as far as when it happens but most commonly occurs when a new VST or DSP is invoked and cpu usage increases. If I stop the playback, whack the panic button a few times and then go to SpeedswitchXP and change the cpu throttling from Max Performance to something else like Max Battery and then back, the very same pattern that just freaked out plays back normally at 30-40% cpu … until it cracks again (within 30secs or so).
I just installed a clean copy of XP to test all this. The computer I’m working with is a Acer Laptop Aspire 2010 with a 1.5ghz Centrino CPU and 512mb ram.
Could something be wrong with my cpu throttling? The only clue I have sofar is that if I mess with the throttling the problem is corrected but only to happen again. I don’t have this problem when working on sample based tracks but also they use very little cpu (20-30%). My problem with VST tracks will occur on tracks that use 40-60% cpu.
That, and stripping it down to the bare necessities has made my system more stable (1.86 centrino laptop with 512MB running Vista Beta 2).
Just today, I’ve added another gig of memory, and it really does do a lot for overall responsiveness. I’ll give your test2 a try later tonight, both with and without the added gig of memory, just to see what happens.