Disabling processing when input is silent. Worth it?

[AdmiralQuality]

The idea here is that the CPU's instruction cache works better if chunks of code aren't popping in and out of it constantly

Even if it was true (and it's not for instruction cache, but may be for data cache if you don't have many plugins), that would be one more reason NOT to process silence. By not doing anything, you would then not be polluting the cache.

Cache has to re-load the code then. If the code (or data) never stops being used, it'll stay in the cache. Of course in audio, much of the data is constantly new so the cache can't help much at all there.

So total overhead becomes more than if it was constant load.

That's the theory anyway. I'm certainly open to debate on that cuz, as JBM gleefully points out, I'm not the lowest level programmer you'll ever meet. Looking forward to comments from someone who actually knows.

[Jason Brian Merrill]

That's the theory anyway. I'm certainly open to debate on that cuz, as JBM gleefully points out, I'm not the lowest level programmer you'll ever meet. Looking forward to comments from someone who actually knows.

i didnt gleefully point anything out, ho!

[tony tony chopper]

Cache has to re-load the code then

why would it be lost? you think caches empty themselves for no reason when there's nothing new to load in?

[Kingston]

Cache has to re-load the code then

why would it be lost? you think caches empty themselves for no reason when there's nothing new to load in?

could be he's doing a bypass routine that empties temp caches... but I can't see why one would need to do that.

[grymmjack]

Oh, and as I've tried to say about 100 times here, NOT TALKING ABOUT SYNTHS. The synth I'm building does kill silent voices... that's just the obvious way to do it for a synth. Though I'm so strongly in favour of constant load that I am seriously considering making this an option for the synth.

*edit*

AQ; if your synth is going to have an /option/ to use full load always regardless of active poly, yikes, wtf? who would ever turn that on? the logic is you know what you are getting into, and okay fine, but you don't make music trying to predict how much you will need do you? isn't the flow just perform, and adjust/throttle as needed for each composition? how would this benefit someone? can you explain in more detail? like even in the most extreme scenario -- a live performance on stage, i don't understand how it would benefit if it was always hitting max CPU needed or not. most hosts, etc, run /better/ with more CPU at their disposal yeah?

[aciddose]

i cant believe you guys are still on about this. i said the issue is simple, the implementation is often complex, and you need to shut the f**k up if you dont write your own code, otherwise, also shut the f**k up but do whatever you want to your own code.

if bypass isnt implemented (and i'm not talking about vst bypass, i mean completely internal to the plugin) there is probably a reason for that, and if you have a specific irk with a specific plugin, go bitch at the coder of the plugin.

aq; there is absolutely no reason to process data that does not need to be processed. this 'cpu load switching' is just as much bullshit as discussions about imaginary adc/dac 'problems' like "lagging transients". unless you switch so often that you have to reload the cache faster than it takes to load it, there is no problem. if it takes 1us to fetch data from ram, and you switch on/off every 100ms, where is the problem? the overhead will be in time, 1/100000th. for every unit of time, you'll spend 1/100000th of that unit fetching from ram due to switching.

[AdmiralQuality]

Oh, and as I've tried to say about 100 times here, NOT TALKING ABOUT SYNTHS. The synth I'm building does kill silent voices... that's just the obvious way to do it for a synth. Though I'm so strongly in favour of constant load that I am seriously considering making this an option for the synth.

AQ; if your synth is going to use full load always regardless of active poly, yikes, wtf?

"...I am seriously considering making this an OPTION for the synth."

It would be an option. If you don't get it, turn it off (or rather, don't turn it on as I'd have it default to normal voice killing behavior.)

You guys and your knee-jerk responses. So eager to judge.

[nuffink]

i cant believe you guys are still on about this. i said the issue is simple, the implementation is often complex, and you need to shut the f**k up if you dont write your own code, otherwise, also shut the f**k up but do whatever you want to your own code.

Is it ok with you if we don't shut the f**k up?
I only ask because not shutting the f**k up about this kind of thing is what this forum is all about.
Mind you, it would reduce the background noise around here if you followed you own advice.

[grymmjack]

Oh, and as I've tried to say about 100 times here, NOT TALKING ABOUT SYNTHS. The synth I'm building does kill silent voices... that's just the obvious way to do it for a synth. Though I'm so strongly in favour of constant load that I am seriously considering making this an option for the synth.

AQ; if your synth is going to use full load always regardless of active poly, yikes, wtf?

"...I am seriously considering making this an OPTION for the synth."

It would be an option. If you don't get it, turn it off (or rather, don't turn it on as I'd have it default to normal voice killing behavior.)

You guys and your knee-jerk responses. So eager to judge.

yeah you caught me, re-read the edited version. i read it again and realized it wasn't what i wanted to say, the edited version i just edited (probably while you were posting this) is. apologies.

[AdmiralQuality]

No worries grymm. Thanks.

Oh, by the way, I did test Hawk's host-in-progress after all and was quite impressed. Congrats to the both of you and good luck with it.

EDIT: Oh and in response to your edited comment... I usually find that hosts run fine right up to the point that they don't. (As I like to say, computers are binary, they either work or they don't. ) Its not like I can sell spare processing power back to SETI or the Human Genome Project.

Now, I do appreciate that this is a MUCH stronger argument for synths than it is for the effect case, which is what I was asking about. But just wanted to illustrate that, to me anyway, I even perceive some advantages of doing it for a synth (maybe, won't really know until I try.)

Cheers.

[Jason Brian Merrill]

"I usually find that hosts run fine right up to the point that they don't. "



absolutely enlightening

[AdmiralQuality]

"I usually find that hosts run fine right up to the point that they don't. "



absolutely enlightening

Glad you're having fun dude.

Meaning that if I'm using 60% vs. 65%, who cares? As long as I don't use 90% because somewhere around there is where things go FARRRT and never recover (at least not until I stop the transport and bypass-cycle all the plug-ins... or even be forced to reload the friggin project because the host is hopelessly sick).

So with a constant load, that's less likely to happen by surprise in mid-performance -- though it does depend on what kind of work you're doing. Recording from mics is a totally different thing than running a bunch of softsynths. Obviously with synths, if you play too many notes and don't have polyphony limited, you run the risk of going overboard just from what you play. The audio recording model is a little more straigtforward... and a better candidate for constant load.

[aciddose]

if the host does that it is either a serious problem with a plugin or the host. possibly a problem with code which is not thread safe.. i'm not sure. could be NaN being passed down the signal chain, could be a lot of things; it shouldnt happen at all. something is seriously f**ked if it happens.

nuffink; dont mistake my use of a few expletives as hostile behaviour, i only ment to suggest that this type of argument (expecially when i see here you guys repeating the same thing over and over. 'POINT OF VIEW A!'... 'NO! POINT OF VIEW B!' rep.) is a bit pointless and really will not lead anywhere regardless of who wins.

[BarendB]

i cant believe you guys are still on about this. i said the issue is simple, the implementation is often complex,

Just check in- and output signals. If the output is silent for a period longer than the longest feedback buffer and the input is silent too, you can turn it off safely. How is that complex?

[nollock]

Cache has to re-load the code then. If the code (or data) never stops being used, it'll stay in the cache. Of course in audio, much of the data is constantly new so the cache can't help much at all there.

But your plugin isnt the only code thats running, it's a tiny part of an overall process loop. And with the small size of instruction caches, 64k on Athlon, 12k trace instructions on P4, there is almost no way your code will be still in the cache by the time it's turn to run comes again.

Even in the extremly unlikely event that the overall DAW process loops is so small so as to fit in the cache, soon as it has finsihed the GUI thread runs and then the Cache will be wiped clean of audio code anyway.

So total overhead becomes more than if it was constant load.

You are cluching at straws, sorry.

That's the theory anyway. I'm certainly open to debate on that cuz, as JBM gleefully points out, I'm not the lowest level programmer you'll ever meet. Looking forward to comments from someone who actually knows.

1) You have no posible way to make sure your plugins code stays in the instruction cache between process calls.

2) Given the amount of processing modern DAWs do in each proccess block, it is almost inevitable that its code wont stay in there inbetween process calls.

3) Give the usual large block sizes (eg 128 samples), the overhead of loading the instruction cache for the first run through your process loop will be fairly insignificant inr espect to the time for the whole block.

4) Processing silence will load your plugins code, and hence push other code out of the cache, it will cause cache polution. the benefit you sugest from not pusing code in and out is worsened by processing silence, not lessened.

HTH

chris