View Issue Details

IDProjectCategoryView StatusLast Update
0001235OpenMPT[All Projects] Feature Requestpublic2019-07-05 21:30
Reporterharbinger Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status newResolutionopen 
Platformx64OSWindowsOS Version7
Product VersionOpenMPT 1.28.05.00 / libopenmpt 0.4.5 (upgrade first) 
Target VersionFixed in Version 
Summary0001235: Option to clear buffers before playback
Description

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.

TagsNo tags attached.
Has the bug occurred in previous versions?
Tested code revision (in case you know it)

Activities

Saga Musix

Saga Musix

2019-07-03 18:17

administrator   ~0003972

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:

  • A plugin will not require more CPU power if there is any leftover audio from before stopping playback. This cannot overload your system.
  • OpenMPT clears all of its internal audio buffers that are sent to plugins when restarting playback.
  • OpenMPT tells plugins to flush their internal buffers when restarting playback, which some plugins don't do. When they don't, you hear e.g. reverb tails from before stopping playback slowly fading out, but it is not related to the CPU usage of those plugins, and it doesn't create any more CPU usage than a freshly triggered note after resuming playback. However: The process of restarting plugins may cause some of them to take long a long time to re-initialize. It's the opposite of what you observed: Telling the plugin to clear its buffers makes it take more CPU time in fact.

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.

harbinger

harbinger

2019-07-05 17:02

reporter   ~0003975

Well, what's happening is this.
After stopping playback of a pattern by clicking on MPT's stop button, MPT faithfully immediately halts all audio playback. Generally i will make edits, but this doesn't matter. When i press either the Play Pattern button or Play Song button, leftover audio continues to "release" for lack of a better word, while the plugins try to play the notes at the beginning of the pattern. There has be some processing going on, on some level, because the resulting audio layers (those releasing and those starting) are so numerous that the audio starts off choppy. As the old, released audio "finishes out," the choppiness goes away.
(One workaround i have is to lower the sample rate that openMPT plays like to 32000, but some plugins don't like that, and they or the plugin bridge will crash.)

You are right — i'm assuming here, and maybe falsely. But these are educated assumptions. I don't know what you know...

Saga Musix

Saga Musix

2019-07-05 21:30

administrator   ~0003976

leftover audio continues to "release" for lack of a better word

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:

  • An audio driver that takes a while to initialize properly. Typically this is completely independent of whatever plugins are loaded and the audio should actually not be choppy.
  • Restarting the plugins (and cleaning their buffers) takes longer than expected. An option to do the opposite of what you requested - to just keep the plugins running and never clear their buffers - might be more useful here, and in the long run it's something we want to have (optionally), as it's more akin to what other DAWs do.

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.

Issue History

Date Modified Username Field Change
2019-07-03 14:22 harbinger New Issue
2019-07-03 18:17 Saga Musix Note Added: 0003972
2019-07-05 17:02 harbinger Note Added: 0003975
2019-07-05 21:30 Saga Musix Note Added: 0003976