[BUG] Loading certain A1 models after A2 models can cause audio crackling / dropouts

[benediktadams]

Hi,

we discovered a hard-to-reproduce issue, where certain A1 models will not play correctly when loaded right after certain other A2 models. Re-instantiating the plugin (prepareToPlay call) will resolve the issue.

We discovered this on our own implementation of the NAM Core (which uses none of the Gateway plugin harness), and verified it on Gateway, which leads us to believe the issue lies with the NAM Core itself.

See the following video reproducing the issue on Gateway.
https://github.com/user-attachments/assets/e36ccd2e-7875-4f88-9366-a179ecb721d2

Additionally you can find Models used on video.zip here.

Please let me know if you need any additional information.

[sdatkinson]

Care to clarify this?

We discovered this on our own implementation of the NAM Core (which uses none of the Gateway plugin harness), and verified it on Gateway, which leads us to believe the issue lies with the NAM Core itself.

NAM Core is a DSP library; Gateway is a private fork of NeuralAmpModelerPlugin...what's the "Gateway plugin harness" that this library uses? And are you saying that this can be observed without putting this library in a plugin? Would a test that just instantiates a model a bunch of times and keep checking the predictions maybe expose the bug?

Thanks for the video & models; I'll get to them later.

[benediktadams]

Yeah sorry for the confusion.

We’re using the NAM core in our own plugin, where we discovered the issue. This plugin uses no code from the NeuralAmpModelerPlugin, but is a custom juce implementation around the NAM core.

We used Gateway to confirm that the issue is not in our juce plugin code, but that it happens (probably) in the NAM Core. That’s what the video shows.

Hope that helps

[squatchlr]

Following your suggestion,
we ran the two models from the zip through a Core-only harness: no plugin code,
staged as the plugin does (get_dsp → Reset → SetSlimmableSize), at 64- and
512-frame blocks.

Swapping models doesn't change the A1 model. The A1 output was bit-identical
to a fresh load in every case:

• after the A2 model ran at slim 1.0, then was destroyed;
• the same at slim 0.0;
• with the A2 model kept alive, its slim toggled every 50 blocks, and the A1
  model processing in between.

We checked this on v0.5.3, v0.5.4 and main.

What does reproduce it is a host calling process() with more frames than
it passed to Reset(). The A2 fast path grows its buffers and plays on. The
generic WaveNet, which every A1 model uses, only asserts, so a release build
writes past its buffers. A host that under-reserves would therefore sound fine
with A2 models and corrupt the heap with the next A1 model, until
prepareToPlay resets it with the real size:

sequenceDiagram
    accTitle: Buffer size across an A2 to A1 model swap
    accDescr: The host announces 512 frames and later calls with 1024. The A2 fast path grows itself and keeps playing. The next model, an A1 WaveNet, is reset with the stale 512, and the 1024-frame call writes past its buffers until the host prepares again with the real size.
    participant H as Host
    participant P as Plugin
    participant A2 as A2 model (A2FastModel)
    participant A1 as A1 model (WaveNet)
    H->>P: prepareToPlay(48 kHz, 512)
    P->>A2: Reset(48 kHz, 512)
    H->>P: processBlock(1024)
    P->>A2: process(1024)
    Note over A2: 1024 > 512: SetMaxBufferSize(1024)<br/>(a2_fast.cpp:735-736), grows, keeps playing
    Note over P: still holds 512 from prepareToPlay
    P->>A1: get_dsp(), Reset(48 kHz, 512)
    H->>P: processBlock(1024)
    P->>A1: process(1024)
    Note over A1: the assert at model.cpp:827 is compiled out<br/>1024 frames go into 512-frame buffers (from :820)
    H->>P: prepareToPlay(48 kHz, 1024)
    P->>A1: Reset(48 kHz, 1024)
    Note over A1: fits again, which is the workaround in the report

Loading

What one oversized call overwrites (the zip's A1 model, reserve 64, call 128)

@benediktadams, two things would tell us whether this is your case:

• Does processBlock ever get more samples than you passed to Reset?
  JUCE calls maximumExpectedSamplesPerBlock "a strong hint" and asks plugins
  to "program defensively in case a buggy host exceeds this value".
• Does the crackling stop if you reset with a much larger size?

#340 makes WaveNet split such a call into reservation-sized chunks: no
overflow, no allocation, and the same output as the host making those calls
itself.

One thing we can't check: the open-source plugin's ResamplingNAM throws on an
oversized block. If Gateway kept that check, the Gateway reproduction points
somewhere else.