Surge: VST2 Linux cracking and popping noise in Bitwig and other DAWs

[davephillips]

Surge built from source
Linux Fedora 23
GCC 5.3.1

I'm getting some really awful sounds from Surge in Bitwig 2.3.5, Ardour 6 beta, and VCV Rack's VST Host. When I play a sequence I typically get cracking and popping noises that sometimes subside, sometimes not. I also get stray sounds that clearly have nothing to do with the loaded preset. Occasionally the noise disappears but only briefly.

I noticed that it helped to switch some presets from poly to mono. Others were unaffected by the switch.

I run a JACK-based audio system at 48 kHz with a period of 256 samples. Could this be a problem for Surge ? It's not a problem for any other native Linux VST I run here, including the u-he synths and Modartt's Pianoteq.

Any & all advice on this problem is appreciated. The GUI looks great, and I've had hints of how good it can sound. Alas, it's unusable for me until I can resolve the audio performance issue.

I know how to use gdb. Anything I should be looking at for debugging purposes ?

Finally, some words of praise and encouragement. I've been following the Linux development here, you've all done fine work. Thanks to the original author for placing his work in the open-source arena, and vast thanks to everyone who has been working on the ports. You are all appreciated. :)

[baconpaul]

Are there any patches which are particular problems?

I wonder if it is a 48k vs 44.1k thing. I presume this isn't something you could try at 44.1 is it? (Not that we shouldn't fix it but would be good to know).

Thank you for the kind words! They are great to see on a Monday morning?

[baconpaul]

So interesting

I took my sample "test a few surges" logic pro track. Took it from 44.1 -> 48 and it played. Took it from 48 -> 96 and it played. took it 96 -> 48 and it played. Took it back 48 -> 44.1 and clicks and pops and clicks and pops. No sound. Restart logic pro (which is saved at 44.1) and no problem.

So clearly something about swapping sample rates can make the synth get in a wedge state. Wonder if that's it.

[baconpaul]

Oh another handy thing: how do I make my jack and bitwig run at 48k in my linux vm? May help me debug. If you can save us (or me!) the googling I would appreciate it

And from reading the code - once you get in a state with pops if you go to init saw patch and change the oscillator 1 to sin does it still pop? Wild guess from reading code while out and about

[davephillips]

Hi Paul ! Thanks for looking into this so quickly. I also downloaded and installed the prebuilt versions. Interesting results: In BWS (with 1.6.0 beta5) I got the noises when entering notes but no noises on playback, regardless of preset chosen (i.e. the preset played cleanly after entering the notes). Ardour6 beta loads the plugin fine but there's a lot of noise on playback. The VCV VST Host works but it's noisy at first, then the good sound prevails. Alas, certain presets cause consistent problems, e.g. the Crisp PWM in the Monosynth (hard) category.

I haven't yet tested the nightly build, will do that today.

[davephillips]

I tried the init saw preset, got the popping. Changed the Osc1 waveform to sin, still got popping sounds, like the attack rate is clicking instead of ramping. I notice that sometimes the noises occur when no notes have been played.

re: JACK - I use QJackCtl to control it, but the command line options for my system would be something like this:

jackd -R -d alsa -r 48000 -p 256

where -R indicates realtime status. Change it to -r for non-rt performance. The other -r is an alsa backend option to set the sr. The period size can be changed to any other power of 2, 1024 is the default if you want to leave it alone.

[baconpaul]

Yeah that’s exactly how mine sounded too. I got an 18db overload click. From reading the code the sample rate change resets all wavetables and sin is special which is why a check helps. When I’m at a desk next I’ll look at the envelope and sample rate interaction. Or if you see anything wrong there too let me know!

Thanks for the info. Super helpful.

[baconpaul]

OK here's a somewhat more nuanced bug report from logic, where I'm having a hard time making it pop.

When it doesn't pop, if I change the sample rate and restart my sample, the first notes don't sound or sound with the wrong envelope.

So it sounds like the ADSREnvelope is "remembering" its position incorrectly somehow when you change sample rates. So looking there for a bit.

Clearly the sound engine goes wrong when sample rates change though. Something in that code is not fully resetting. If your engine is 48k I wonder if you get set to 44.1k at startup (because that's some default) and then set to 48k once you run so you run into this problem.

Do you have the ability to build a version with a print statement in it and see stdout? If so, I'd be curious how many times SurgeSynthesizer::setSampleRate is called and what the values you see are in your setup.

[baconpaul]

paul:~/dev/music/surge$ grep -r 44100 src
src/common/unitconversion.h:static float env_phasemulti = 1000 / 44100.f;
src/common/gui/COscillatorDisplay.cpp:      float disp_pitch_rs = disp_pitch + 12.0 * log2(dsamplerate / 44100.0);
src/common/gui/CNumberField.cpp:      float rate = lfo_phaseincrement(44100 / 32, value);
src/au/aulayer.cpp: float sampleRate = 44100.f;
src/headless/main.cpp:    surge->setSamplerate(44100);

lemme fix that aulayer one first. But the tunitconversion one looks like it could be a problem...

[baconpaul]

OK the aulayer one should be fixed but the unit conversion one is just for a text display and is matched in another spot. But basically: Swapping 44.1 <> 48 over and over in AU logic even with the aulayer fix ends up with me getting clicks. Something - I don't know what but something - doesn't survive sample rate reset.

Ugh. State is a pain in the neck.

Not clear this is your problem either @davephillips so let me drop this in another issue just in case.

[davephillips]

Hi Paul,

Do you have the ability to build a version with a print statement in it and see stdout? If so, I'd be curious how many times SurgeSynthesizer::setSampleRate is called and what the values you see are in your setup.

Sure, I think I can do that.

[baconpaul]

Cool. @tank-trax reports similar problems. Something is amiss with sample rates for sure. Not sure if we have one or two issues tho...

[tank-trax]

I noticed that when it clicks and pops it's often the left channel that is red lining.

In Bitwig. Buggy Brass from Polysynth clicks but on the right channel. I did not have to close it. Just navigated through other presets and now no clipping. Seems intermittent.

In Renoise. Monosynth (smooth) Photon is clicking. This time on the right channel.

[occulkot]

Yesterday i tried to play with surge a little (self compiled / renoise host).

Ive got clicks n pops immediately after playing with "init" preset. When ive changed presets with +/i buttons i could play with it a little. But ive noticed that "poly mode" info raise up really fast from 1 to 8 (and more) and when it hit 9 i've got "c'n'p".

[baconpaul]

@occulkot thanks for the report. Can you let me know (1) what flavor of linux and (2) what bitrate you are running at?

Are the clicks and pops interspersed withsound or just the only thing you here.

Very interesting on voice; sounds like release is wrong somehow also. How are you generating inbound notes?

[occulkot]

@baconpaul, im running it on arch linux, ill post more info later, when ill return to home.

[baconpaul]

Thanks. I am pretty sure there is some uninitialized memory somewhere but I can't quite find it yet. Linux is "worse" with uninitialized memory (or "better" to find bugs) since it really ends up more random than on macOS for some reason I don't quite get.

If you reliably get clicks and pops, also running the headless app (which you can get with ./build-linux.sh build --project=headless) and seeing if any of your RMS peak could be super useful.

On macOS I can pretty reliably get the pops if I switch sample rate enough so I suspect that the global tables that drive envelopes are wrong; similarly when I don't ever set sample rate I get the same pops I get when it wedges on mac. So something in the path is not using correctly configured envelope tables. Not sure what.

Any info appreciated.

Oh and just as an FYI: We are releasing beta 7 tomorrow then I'm taking a couple of weeks of no surge development so will be less responsive.

[occulkot]

I understand, I will try to record video with renoise and headless build
and maybe it will help you somehow.

On Wed, Mar 13, 2019 at 2:21 PM Paul [e-mail] wrote:

Thanks. I am pretty sure there is some uninitialized memory somewhere but
I can't quite find it yet. Linux is "worse" with uninitialized memory (or
"better" to find bugs) since it really ends up more random than on macOS
for some reason I don't quite get.

If you reliably get clicks and pops, also running the headless app (which
you can get with ./build-linux.sh build --project=headless) and seeing if
any of your RMS peak could be super useful.

On macOS I can pretty reliably get the pops if I switch sample rate enough
so I suspect that the global tables that drive envelopes are wrong;
similarly when I don't ever set sample rate I get the same pops I get when
it wedges on mac. So something in the path is not using correctly
configured envelope tables. Not sure what.

Any info appreciated.

Oh and just as an FYI: We are releasing beta 7 tomorrow then I'm taking a
couple of weeks of no surge development so will be less responsive.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/surge-synthesizer/surge/issues/660#issuecomment-472418785,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABtduedkhpzSoFuNgB_VoqRpNtTH8vqtks5vWPtWgaJpZM4bP0rE
.

--

Pozdrawiam
Mateusz Ratajski
http://exp.pl
509 305 409

[baconpaul]

Thanks. The more info we get the better. We have to fix this before we drop the beta label; quite a few (but by no means all) linux users experience it as does the occasional mac or windows user (but on mac and windows it is transient; if you remove and restart the surge plugin it almost always goes away)

[occulkot]

The surprising thing is when i try to record video at work with version compiled just now i don't get any c'n'p.
I built it just yesterday at 22:00CET and definitely had a problem. Ill try without recompile at home and again with clean compilation.

[baconpaul]

Yeah the problem is persistent and transient both. If you find non osthslogical ways to catch it repeatedly that’s very very valuable. We can keep getting it once in a while then debug and don’t. Tough one....

[occulkot]

Here is video from homestation - https://www.youtube.com/watch?v=PRqRkBUuKXs.
As you can see, clicks starts after first note is sent with init preset and
then happens also in next selected preset. I didnt notice raising poly
voice info now, but when voice count gets to 8 i get clicks again.
Switching presets with +/- seems to change the behaviour.

Im currently running ./surge-headless and will provide log soon.
Ive also checked changing jack rates, but didnt noticed any difference.

edit: home version changeset: commit 9a994c4ec9fe027b523cac02f465ea6000d1985
work: commit 91debf4ddd6678929717c4cc1ab4a1d04af84e10

[occulkot]

headles results - https://pastebin.com/EmXqkrH8 from homestation.
Im currently rebuilding from master commit and will update you with results.

[occulkot]

Hah, same problem. I even copied compiled version from work and have the same (clicks) results. Maybe problem is somewhere else? Some OS libs? I dont tend to update homestation frequently, but it was updated around 4-5 months ago. Ive checked libs used by jack/renoise/renoise plugin hosts. All looks like same version. Dont know what can i check else.

[baconpaul]

Just checking: is home 48khz and work 44.1khz? I can break it on mac (but not in headless) around the sample rate changes. Wonder if that’s part of it.

[occulkot]

Ive change home to 48, 44.1, 96k. All give same results. At work i had it running on 44.1. You can see at the video that c'n'p returns when polyphony info get to 8 voices. While playing around now ive seen 9/8 voices for a moment but i dont think it is related to this problem as with "init" preset when poly info shows only 1/8 voices.

[baconpaul]

Yeah the voice stealer is best efforts polyphony and will sometimes go above the limit if you play quickly. But it is interesting that the voice steal section is what causes the cnp for you. Those voices will be in a ‘release’ state. But I don’t have the entire state diagram clear yet anywhere (other than when i stare at the code).

Hmm... like I said I’m about to take a 2 week break from the project - will be infrequent until April once we cut beta 7 - but here’s some thoughts:

if you get a clip in audio but no blown out values in headless it means your problem is somewhere between process() and the vst2 filling up the buffer. Could happen if you stall or if you mis-copy values. Perhaps in the vst2 render where we do a copy of process() block results, try doing a copy of only 0. Then if you get click n pop still you will know that either we are stalling or we are not writing the write memory region. This is all in src/vst

If when replacing the output of process with 0s you end up not getting c’n’p then there’s the (unpleasant) debug step of scan the buffer you are generating to see if any value is above 3 and segfault if you do so you can catch the state in the debugger.

Those are things I would try when I’m back. And I am more than happy to have someone else find this bug so welcome you to dive in!!

[davephillips]

Well done ! I've been playing with it in Bitwig 2.3.5 (on Fedora 23 Linux), it's working beautifully now. Kudos to all involved in this very fine work, I'm looking forward to using Surge more often. :)

[baconpaul]

Thanks! The nightly should have the fix in place for the uninitiated case now and we will get it out in a beta 8 soon. Appreciate letting us know it works well for you!

[occulkot]

Everything is fine at mine renoise too. Many thanks for fix!