If you drop an audio buffer and fire off a 22kHz impulse into a 50,000 watt soundsystem, you are going to have thousands of very unhappy people and likely some hearing damage.

Point taken, but 22khz is too high for people to hear I think.

You don't need to perceive a sound to have your ears be damaged by it.

(This goes in both directions on the spectrum too. You can have your hearing damaged by infrasound as well.)

Ah, this makes a lot of sense, thank you. Much like there are spectrums of light we can't see that can damage the eyes.

Idk exactly what the poster meant but an impulse is broadband, theoretically encompassing all frequencies representable in the host sampling rate.

Yes, it absolutely 100% will, depending on what you mean by handwaving “glitch”. VST is built into chains, and a flaky plugin will derail an entire performance, often making downstream plugins crash. I’m speaking from extensive experience writing plugins and performing with them in multiple hosts and trigger setups. It’s not a robust protocol, but it gets the job done.

Are you speaking from some experience with which I’m unfamiliar where it’s okay for DSP code to fail hourly? Trying to understand your viewpoint.

Agreed. If anyone wants to see some of the more successful DSP work being done today for pro or prosumer audio, I recommend checking out Strymon and Universal Audio products. Both make use of SHARC SoCs and achieve great results.

Are there any VST containers? Something that will wrap the VST, intercept under-runs or other bad behaviour and substitute some alternative signal (zero, passthrough, etc.). This could also be part of the host software.

The article and your comments inspired in me the idea of a wave-net based VST learning wrapper. If the real plugin fails, substitute a wave-net based simulation of the plugin.

Underruns are not bad behavior. It's the host application's responsibility to hand VSTs buffers to process, and the VSTs themselves have no concept of how much processing time is available to them (except a method that signals to distinguish real-time processing from offline processing) or what it means to underrun the buffer.

The behavior you describe (zero signal on underruns) is a common mitigation. The DAW or the driver itself initializes that'll eventually be handed to the sound card to zero before the host application requests the plugins to process, and if it doesn't have time to mix the plugin outputs it'll play back the initialized buffer instead.

From aea12 one might think that it's normal for an underrun to be fatal. Because underruns are not an exceptional occurrence during production (where you might occasionally load one plugin too many or run a different application with unpredictable load characteristics like a web browser) it really isn't an unexplored area and although they're are a pretty jarring degradation I've never experienced crashes that directly correlated with underruns.

Hey @aea12, would you be available for a quick chat? My email is in my profile. Thank you!

A VST that doesn't fill its buffer on time shouldn't crash another plugin. It's your other plugins that are flaky.

To expand on this, each plugin will receive host managed buffers that they're requested to fill and the input they're expected to process. If they don't do that in time for the host to mix the buffers and deliver the mixed buffer to the audio driver, it simply won't. Nowhere do the plugins directly interact through this process.

If your plugins are crashing because of an underrun you have a much more serious problem than underruns. Then you have plugins writing to or reading from memory that wasn't either handed to them by the host or allocated by themselves. That bad code running in your process can cause it to crash is an orthogonal problem to buffer underruns causing skips or stuttering in audio.