Tape kills audio when oversampled

[Andreya-Autumn]

Load a Surge in Reaper Oversample it to 196k Latch or something Load the tape FX Sound dissappears.

[ritschwumm]

.oO(NaN-poisoning?)

[Andreya-Autumn]

Yes maybe.

Notably, this only happens if the oversampling is already in effect when loading the Tape, so initialization-related probably.

[baconpaul]

right so at 192 in my debug build pulling in a tape on an empty surge just sends CPU to 100% let me try a release build to check also

[baconpaul]

OK so if you do this at 192 and run the mix the original sound comes back so the FX isn't borked completely If you do it at 96 you get a big cut but not to 0

I really think this is somewhere in the DSP missing a sample rate reset but i can't see where.

[Andreya-Autumn]

Push out of milestone so we can 1.2 sooner?

[baconpaul]

Maybe

I’m curious about the init cycle part thoiugh so let’s leave it float for a bit

[mkruselj]

We probably need @jatinchowdhury18's eyes on this one, I guess?

[baconpaul]

yes i think we will. i'm not seeing it.

[jatinchowdhury18]

I believe we spoke about this issue a little while ago on the Discord... If I remember right, the bug was only presenting itself when using smaller block sizes? I remember having some trouble reproducing this one as well.

[baconpaul]

I saw it at 32 yesterday in reaper once I learned how to oversample by track

[jatinchowdhury18]

Hmmm, I did some more testing today, and still haven't been able to reproduce. Currently I'm testing with the nightly VST3 in Reaper 6.68. I've tried both "Chain oversampling" and "FX instance oversampling", but maybe there's some other way of doing per-plugin oversampling in Reaper?

Just trying to narrow down what could be the differences.

[mkruselj]

Those are the only ways to do plugin oversampling in Reaper AFAIK.

[jatinchowdhury18]

Hmm okay... I was also testing on my M1 Mac. Maybe the issue only shows up on Intel? Or only on Windows? I can give those a try tomorrow.

[Andreya-Autumn]

And just to be sure Jatin: You're oversampling first and then loading the Tape FX right?

If the tape comes before the oversampling there's no problem, it's initializing the tape while oversampled that causes issues.

And I'm on M1 too... Hmm... I'm on Reaper 6.77, but it seems unlikely they changed something that borked this between .68 and .77 right? What OS are you on?

[Andreya-Autumn]

Oh hey, Nimbus does it too it seems. EDIT: But none of the others.

Same symptom for Nimbus and Tape though. They'll let dry sound through with the mix dial, but not make any sound otherwise if initialized while oversampling to at least 192.

EDIT AGAIN: Curiously, I can only repro this with the chain/instance oversampling. Setting the host sample rate or the project sample rate to 192k doesn't cause the problem for me. Very weird...

[mkruselj]

Nimbus uses libsamplerate internally to modify its internal 48k sample rate to whatever the host is doing. Not sure if Tape uses that same lib or not, but therein might lie a clue...

[baconpaul]

My suspicion is that reaper oversampling is doing something like: creating at sample rate SR then resetting sample rate to SR * 4.

These FX - I bet - are dealing fine with arbitrary SR but have a bug in SR reset.

They will be different bugs - I'm really quite sure tape doesn't use libsrc

One thing to try would be to put a print statement in 'SurgeStorage::setSampleRate' and see what values reaper provides us when.

This is just a guess but its a guess which fits the evidence presented I think.

[baconpaul]

Nimbus is a separate bug of breaking when the oversampling ratio fills two blocks to make a Inout down sample block

[baconpaul]

Nimbus was fixed in 1.2.0 so renaming this issue back to just tape

[mkruselj]

@Andreya-Autumn I am not sure I can reproduce this one anymore, how about you?

[baconpaul]

I wonder if ti is the same sample reset change issue that the BBD Ensemble had? @jatinchowdhury18 ?

[mkruselj]

It seems Tape effect is setting SR related stuff in init() but sampleRateReset() virtual method is not overriden. So that might be the case!

[Andreya-Autumn]

So that PR doesn't solve it unfortunately. But it did change something, which opened some new leads. With that change, more of the noise added by "amount" survives the oversampling. Interestingly it's amplitude is samplerate-dependent (quieter with more OS), but not its frequency response.

Investigating some more led to the realization that the signal is actually still there, but extremely quiet! Specifically:

Load Init Sine and play a fifth, peaks around -14dB here. Oversample 8x and load Tape - Init Add 72dB of gain (limiter advised obviously) The sine is back!

[Andreya-Autumn]

If you mess around with the Loss controls, you can raise the signal some. Setting IPS to 1 and spacing around 10nm you "only" need 48db or so to get the level back. Still crazy of course.

But maybe this offers some clues to what's going on? I also tried the actual CHOWtape effect, and found that it also has some misbehaviors with this kind of oversampling, but different ones. I can get it to DC out completely at some settings, but the amplitude loss is not there.

[Andreya-Autumn]

Oh, also this.

CPU spikes up to 100 when adjusting any of the Loss controls (but no others). It's a bit hard to read, but at normal samplerates I think I see it flickering between 8 and 12% while idle, and under adjustment of those sliders it sits still at exactly 10%. 8x oversampled I see it idling between 30-45% maybe, and any adjustment pins it at 100% as seen in the gif.

[mkruselj]

OK I guess we should loop in @jatinchowdhury18 again at this point, hehe 🙂

[Andreya-Autumn]

Yup!

Oh and also, I tried running the sound card at 96k and 192k, instead of using the reaper oversampling. Same issue occurs, so it may not reaper specific after all.

[mkruselj]

So wait, should we merge that PR of mine or does it change the sound of existing projects?

[Andreya-Autumn]

We should not merge it because ultimately it didn't change the core problem. It indirectly helped me find out the things I wrote above, but no reason to merge a change that doesn't fix anything. We can leave it hanging for reference I guess?

[mkruselj]

Sure I could mark it not to close the issue but the thing is it is now doing what it was supposed to do, which is respond to sampleRateReset(), which it didn't. :)

[Andreya-Autumn]

If we can be sure it's a good change otherwise I guess why not. But I didn't test it under more normal conditions so I don't know how we'd be sure? I think the effect sounds the same, but maybe worth checking a little closer.