spike in CPU usage when enabling an effect for the first time

[Be]

I can't reproduce this reliably, but when it happens it causes an xrun. Thereafter, enabling effects works fine.

[Daniel Schürmann (daschuer)]

This is because the Group state is instantiated during the first engine call.
https://github.com/mixxxdj/mixxx/blob/8d191bf7ce2d62d24c6e0ffac4b2afd7359afa8a/src/effects/effectprocessor.h#L80
This new() in the engine thread most likely causes the under-run:
https://github.com/mixxxdj/mixxx/blob/8d191bf7ce2d62d24c6e0ffac4b2afd7359afa8a/src/effects/effectprocessor.h#L97

[RJ Skerry-Ryan (rryan)]

The system was designed to pre-allocate all group state on the main thread for groups that exist when the effect is instantiated.

It looks like this isn't working for the default effect chains because they are created before the decks/samplers/etc. are setup.
https://github.com/mixxxdj/mixxx/blob/master/src/mixxx.cpp#L189

Be: Were you using master or was this using your persistent effects branch? Since you load effects in EffectsManager::setupDefaults(), the loaded effects will also not get their group state pre-instantiated.

It should be safe to move setupDefaults() to after the decks/samplers/mics/auxiliaries are setup.

[RJ Skerry-Ryan (rryan)]

Though this won't work for e.g. the P32 MIDI script which creates 32 samplers when the controller script is evaluated. If you enable an effect unit for one of these samplers you'll hit the same memory allocation in the callback.

It's also wasteful to allocate group state for every effect for all groups -- especially if something like the P32 is creating 32 samplers.

Perhaps a better solution would be that when we write an ENABLE_EFFECT_CHAIN_FOR_CHANNEL message from the main thread to the engine, we also send a message for every effect in the chain containing an instance of the group state for that effect. We will also have to write group state for every enabled channel whenever we add a new effect to the chain.

[Be (be.ing)]

> Were you using master or was this using your persistent effects branch?

I think I have experienced this issue with both, but I'll check when it happens again.

> Though this won't work for e.g. the P32 MIDI script which creates 32 samplers when the controller script is evaluated. If you enable an effect unit for one of these samplers you'll hit the same memory allocation in the callback.

FWIW there is no way with the P32 mapping to assign a sampler to an effect unit.

[Daniel Schürmann (daschuer)]

> Perhaps a better solution would be that when we write an ENABLE_EFFECT_CHAIN_FOR_CHANNEL message from the main thread to the engine, we also send a message for every effect in the chain containing an instance of the group state for that effect. We will also have to write group state for every enabled channel whenever we add a new effect to the chain.

This Sounds like a good plan. .. and entirely remove the singleton thing from the process call.

[RJ Skerry-Ryan (rryan)]

> This Sounds like a good plan. .. and entirely remove the singleton thing from the process call.

Singleton thing?

[Daniel Schürmann (daschuer)]

Not a real singleton, just this:

if (holder.state == NULL) {
    holder.state = new T();
}

[Be (be.ing)]

I am doubtful that the "new T()" in PerChannelEffectProcessor::getOrCreateChannelState is causing this issue. In https://github.com/mixxxdj/mixxx/pull/1254 I have moved the initialization of EffectChains/EngineEffectChains and Effects/EngineEffects after the registration of input & output channels with EffectsManager, but now this issue seems to be occurring more often. Do you have any suggestions for tracking down the source of the issue?

[Daniel Schürmann (daschuer)]

Is this one fixed? I think yes.

[Be (be.ing)]

Yes this was fixed with the EffectState memory handling refactoring for postfader effects in 2.1 https://github.com/mixxxdj/mixxx/pull/1254

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/8793