Red Ranger wrote:cuse wrote:Remember that LinuxSampler was til recently only used for realtime rendering, which means small buffer sizes. I think Andreas already suggested a hack to catch those large buffer sizes ordered by sequencers in LinuxSampler's VST plugin class, and splitting the offline rendering call of the VST sequencer in a loop by smaller, realtime typical period sizes.
Where can I read more on how to perform this workaround?
I have only talked about this with Christian once in a private chat, so you can't read about it anywhere. I wouldn't call it a workaround, it's a change in the code. The DSSI plugin already has this type of functionality, look in PluginDssi.cpp, RunMultipleSynths - there you can see that audioDevice->Render is only called with buffers with max length 128. If SampleCount is bigger than 128, the Render function is called multiple times. The LV2 plugin also has this, maybe it's easier to read.
I'm not sure if this is enough to fix offline rendering though. If the rendering is done faster than real time, I think we need to implement a special mode in LS, where the audio render call waits for the disk thread to fill the buffers. As it is now, if a secuencer calls the plugin faster than real time in order to render audio to disk as fast as possible, the LS disk threads will not keep up.