View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001235||OpenMPT||Feature Request||public||2019-07-03 14:22||2019-07-05 21:30|
|Product Version||OpenMPT 1.28.05.00 / libopenmpt 0.4.5 (upgrade first)|
|Summary||0001235: Option to clear buffers before playback|
When using a lot of CPU-heavy plugins, auditioning a pattern (or the track so far) after making edits will cause the audio buffers to continue, and it spills over into the started playback. This can create sometimes a choppy overrun when auditioning new edits. Occasionally the load is so heavy that it can make it difficult to stop playback as my computer tries to process everything old and new combined.
What we could use is an option to clear the buffers when pressing any play button (which of course will introduce a delay). An alternative, probably less desirable, is a new button which would act separately to clear the buffers before beginning playback.
We could also have an option to allow the buffers to clear when playback is stopped. But this may not always do the job, as some VSTi's will not always respond to stop-playback requests.
|Tags||No tags attached.|
|Has the bug occurred in previous versions?|
|Tested code revision (in case you know it)|
I think there are a lot of wrong assumptions of how things work internally in this report, which makes it hard to decipher what the actual problem is. Let's get some things straight:
If you are talking about what I described in the third point, the only option to improve this is to not clear plugin buffers, which may eventually happen when we implement a mode where OpenMPT's audio output is constantly running. If you tried to describe something different, then I didn't understand it.
Well, what's happening is this.
You are right — i'm assuming here, and maybe falsely. But these are educated assumptions. I don't know what you know...
These are indeed the plugins that do not follow the VST standard 100% and do not clear their plugin buffers when being told to do so. So the option you requested would not help there, as OpenMPT already asks the plugins to clean their buffers. Typically this left-over audio will be a reverb tail.
However, it is extremely unlikely that this reverb tail causes audio choppiness: Whether the source that was fed into a reverb consists of one, ten, one hundred or just leftover voices does not matter in terms of how expensive the reverb is to compute. Once the note has been fed into the reverb, the reverb will do its magic until it becomes inaudible.
There are two typical causes for problems when resuming audio playback in OpenMPT:
Without knowing which audio driver type you use (WASAPI? ASIO? WaveRT?), which other audio settings are used, which plugins are involved (plugins with big sample libraries might be clearing their sample cache and thus cannot start new notes immediately), and what the choppiness you describe actually sounds like, there is little more I can do to recommend a workaround or even take any action in the OpenMPT code.