Ive tested with different buffer settings and there are still crackles. If i press to sampler tab there is a little less crackles but still unacceptable. I guess the issue is with the convolver DSP. May be its an issue with custom IR loaded into it, may be an issue with convolver sample freq conversion algorithm, i don’t know, I’m not so savvy in those things.
p.s. a little update, I’m on osx 10.9.2, not 10.9.1
Hm I believe these are more than one problems: On the one side, there is something going wrong with the convolver, on the other side audio starts to be unstable from 40% cpu on OSX, and also dependent on -some- gui drawings (e.g. not the scopes etc).
press stop button twice , resets audio engine …might work
Convolver indeed creates a few CPU spikes with very large IRs at low buffer sizes. Will check if we can improve things here a bit.
taktik, why does the stuttering go away if I go to sampler?
EDIT: Hm, sadly no real change in b7: Until 14ms, the above song will crackle a lot at that position. If I go to sampler tab, the crackles disappear now completely! Shouldn’t run a single instance of convolver with 8ms like other convolver do, too?
I can use 7 instances of RaySpace convolver plugin with 6ms, but not one from Renoise convolver? Hm…
Some comparison to Logic 8:
I can use 9 instances of rayspace In Logic 8 64bit using 256 samples latency. And I could use additional ~8 or more instances, WITHOUT any crackling!
See here:
Attachment 4791 not found.
So Renoise vs. Logic: 7 vs 17 ?? Sorry, there is a performance problem in Renoise Mac. But I will stop now reporting this.
I know, it’s an older thread, but it seems some people have to learn more about audio buffering…
These glitches and crackles are a result of too small audio buffers. It doesn’t matter how mega fast your CPU is, if your soundcard’s driver have poor audio buffers. The buffers are needed for processing the audio signal, before it goes outside your soundcard, when playing the song in your DAW in realtime, as if it were a realtime audio rendering. The informations will be pre-loaded into a buffer. From there it wil be processed by the CPU. The CPU is taking the pre-loaded informations out of the buffer for processing, while new informations will fill the buffers. The bigger the prohect, the more devices, VST’s, are used in the project, the more information will arrive the buffers the same time. But if the buffers are too small and completely filled with informatons for processing, they can’t load more further informations until the already loaded informations are processed by the CPU. These informations then will be dropped (lost). This information loss causes gaps in the singal and that are then the glitches and crackles you hear. It’s like a glass which is filled up to the top with water. If you then pour more water into the already filled glass, the water will spill over and will get lost. Same happens with the audio informations. This are so called “buffer overruns” or “buffer overflows”. If you then set bigger audio buffers, then more informations can be pre-loaded and processed by the CPU and cause also less glitches and crackles. But is has the disadvantage of bigger latencies because it takes more time to fill up the buffers with infos. But apart from this disadvantage it then has the advantage, that you need less cpu for the processing, because with bigger dada packets which arrive the CPU more infos can be processed by the cpu at the same time.
Now you have to make a compromise: smaller buffrs with less latencies, but may get gliches and crackles, or bigger buffers with more latencies, but without any cracles and glitches…
And: who really needs to work with just 3 ms of latencies? You don’t really notice the diffferences between 3 ms or 5 ms or even 8 ms, while playing your instrument live. Normally the human hearing doesn’t really notice big differences between zero latencies and up to 8 or 10 ms. And for audio processing it also doesn’t matter as long as you don’t work with live setups on a stage. Even with top end hardware, which the pros use for their live setup, you get some latencies, but a good player can learn, to compensate these latencies while playing live on stage.
I have a setup with 256 samples for my audio buffers (ca 5 ms of latencies). On bigger projects i even use 512 samples (ca 11 ms latencies). But these latencies are not too big, so that i was able to learn to compensate these latencies while playing my keyboard.
I use the 64bit version on a quad core
It also depends on the VST’s you are using. Most of older 32 bit vst’s were designed for just one CPU core (because multicore CPU’s were not yet available at this time). So they also will be processed by just one cpu core, not necessary if it’s a multi or single core CPU. And if you have a lot of such plugins inside your project, it can be that they all use the same CPU core for processing, and the dsp meter shows 50%, even when just one of four cores is used. Because these plugins can just use 1 core.
Could this something to do with the 32bit audio bridge? Maybe this is the problem, that the bridge consumes a lot of cpu that is not shown in the cpu meter… I
And it doesn’t have much to do with bridging them to 64 bit. I’m also using a lot of 32 bit plugins via the internal bridge in 64 bit Renoise and never had any issues, on the contrary, in my opinion the Renoise bridge is the best working i ever used. Never had problems with bridging in Renoise. But very often in other DAW’s and their internal Bridge. In my setup they use nearly the same CPU power as in 32 bit Renoise without bridging. The differences of more CPU conumption when bridging normally is so small, that you even can’t notice it.
This bridge is also extremely slow when restoring presets as I reported here
Never noticed here with bridged plugins.
No no no.
Its the gui. reported many times in here.
I never noticed such GUI issues on my system. All works fine here. Even with a mass of CPU-intensive stuff or lots of bridging in my projects. If it’s really the GUI, maybe your graphics card can cause the CPU load? Because it has problems with the GUI rendering and then it will be done by the CPU (maybe even onboard graphics?)? Did you try installing a newer graphics driver? Maybe you use too much visual effects with your OS designs which also affect the CPU?
How i wrote, i had never such issues since i’m using Renoise. On both, 32 bit and 64 bit. It all depends on how good your whole system (CPU, memory, audio interface, even BIOS settigs in some cases, power management, other background processes outside of Renoise like e.g. your antivirus software, the used OS and it’s settings, etc) works together.
I don’t know which OS and its settings you’re using. But a big issue can also be the power management of your OS. If it is set to save CPU or power when it goes into idle mode after doing nothing on the computer for a while. It then shuts down all things, that are not needed at the moment, e.g. it shuts down your harddisks, slows down the CPU, temporarily deactivate the usb devices, etc. It then can take a while, until your system reaches full performance again when you start playing your project. Even if it’s not in idle mode yet. Beause if the system need less ressources at the moment, it will automatically slow down to the minimum possible needs, to save e.g. battery power on a laptop. So if you play the song, it can be, at some points while playing it needs less recources, then the system all slows down, then at other points with more action, it will rise to maximum again. And this back and forth can also cause such issues. In this case then it’s better to set the power management to full performance instead of power saving mode.
… Man, why you are wasting your time and my, too? Just read thru this forum. And I am on OSX, just like the other people with problems. If we minimize the GUI, all crackles and lags are gone. The gui is mostly CPU driven, and somehow produces heavy cpu spikes. It also refreshes uselessly many times, the whole gui like 1000 times in 1/60 sec, just for a status message for example. And I bet, the same performance problems will appear on windows, too, if you looked into it more accurately. Also, you need to use VSTis, not renoise instruments. Why you wanna unprove something that has been already proved? I don’t get it.
The gui also causes a bunch of other problems. On the other side, I really love the Renoise GUI visually. For me the best of all DAWs.
I can live with this problem, because my CPU is quite powerful (Did you see the performance benchmark thread? My system is the fastest there, but only with renoise instruments). Others not, especially people with later OSX versions, which even more uses the GPU for GUI stuff. Renoise could have a much better and solid performance, if the technical side of the gui concept and code were overhauled.
If you’re on OSX, then it seems that it’s a problem with OSX or the OSX version of Renoise. I’m working on Windows 10 64 bit, and, as i wrote before, never had such problems. it doesn’t matter how much stuff is going on in Renoise. Even if i have lots of 64 bit VST’s and also 32 bit VST’s in bridged mode and also lots of Renoise stuff working together, or just VST’s or just Renoise stuff, also if my CPU is going far over 50%. It always works fine here. No glitches while playing, no glitches while saving during playback, no glitches while heavy automation stuff is working, No glitches overall. It doesn’t matter if i switch to the mixer section, to the sampler and wherever, or what VST knobs or controllers of Renoise devices i’m moving. And i also tested the song you posted. And it works like a charm on my system. I just have a maximum of 14,8% CPU usage with my default settings of 256 samples (5 ms latency. So it seems that’s a problem on the OSX side. I even switched my audio buffers down to the smallest buffer size which is possible with my card. This is a buffer size of 48 samples, which produces just 1.1 ms latency. On this settings i get some small glitches and a maximum CPU load of ~23%, but this is normal with such small buffer settings. The next bigger size are 64 samples with 1.9 ms latency and from there no more glitches. Ok, you’re using a quad core 2.5 and i’m using a 8 core 4 GHz. Maybe this also makes a difference.
Yea… I’m using hardware synths and renoise has been crashing after hovering around 50% CPU for too long. I don’t get glitches or pops, it just straight crashes. So now I get a sound I want from the hardware, mix it down to audio, then sample it.
On Windows i found out that keeping drivers and everything updated very often solve problems like this, but i have no idea how that works on a mac though.It’s like oiling a squeaky door.
I also had more luck using the ASIO drivers instead of directsound through the years…
On Windows i found out that keeping drivers and everything updated very often solve problems like this, but i have no idea how that works on a mac though.It’s like oiling a squeaky door.
I also had more luck using the ASIO drivers instead of directsound through the years…
ASIO4LIFE