Yes, I suppose you are correct... But still thinking about it...ishkabbible wrote:I do NOT understand the buffer size vs. CPU load relationship (and your recent test results seem to agree with me). If it takes me X ms to calculate 256 samples, it is going to take me 2*X to calculate 512 samples, and 0.5*X to calculate 128 samples. Where does this change the CPU load? I *can* see how the overhead involved in passing the buffer to the driver plays here, if I am passing twice as many buffers per unit time, I am incurring twice the overhead.
Isn't calculating 512 samples going to take a *little* less time than twice the time it takes to calculate 256 samples? Because of caching and branch prediction... and the way the OS assigns CPU cycles to your code...
It is just a gut feeling, that the more time you give a modern CPU to do the same operations over and over again, it will increasingly do them a little bit faster because it optimizes itself even at hardware level. Please correct me if I'm wrong..., as I said this is more of a ...feeling... I may be saying complete rubbish.
uuh... that's indeed weird... will think about it.ishkabbible wrote:And speaking of experiments, I did one last night that has me very puzzled - I downloaded the MidiOut plugin that just pumps the Podium MIDI commands back out to an external MIDI device, used MIDI-Yoke to pipe this into the standalone Zyn, and had Zyn send the audio straight to the hardware. I figured this way I could get Zyn running on one CPU (which I know works well), with Podium running on another CPU. It didn't work that way. For some reason I was STILL pegging the CPU meter in Podium! And in this configuration (all other channels muted), Podium shouldn't have been generating any audio at all. I will continue to work this as a workaround to the killer-snare patch issue - it SHOULD work dammit
Even if Podium is running on one CPU and standalone zyn is on the other.. they still have to talk to eachother... I'm not sure how MidiYoke deals with this. Another way to have the host on one CPU, and the plugin on another CPU is by bridging them, with a tool like jbridge. I use this when I play with my host, EnergyXT, because this host doesn't support multicore. Hmm...
LE: Ok, forget about jBridge...
I tried the same thing you did, but in EnergyXT.
In the host, I set the output driver to MME (too free the native ASIO driver) and routed the midi out through Midi Yoke to the standalone version (ASIO build). It sort of works, and I see *no* CPU load in EnergyXT, and the only program that's using the CPU being Zyn standalone exe. However! I still hear cracks in the sound if I'm using the ASIO build of the standalone!! If I use the MME version then I hear no cracks but the latency is huge.
To sum it up... if I use the ASIO build, I cannot play around with my mouse on the virtual keyboard without cracks (using the killer patch)... with or without MidiYoke, or other software. Can you?!
LLE: I tried the standalone asio 2008 with 512 buffer size, 512 oscil size and 512 ASIO buffer from soudcard's control panel. And I cannot madly play with the mouse without hearing cracks. While on EnergyXT + VST at the same settings (512 everywhere) I already have a hurting arm while moving the mouse left and right with no cracks in audio. It's strange if it happens the other way around with your setup... Did you originally tried with the asio standalone, or the MME, during your first performance tests?