I just started using the WT VCO, so I don’t have much past experience to draw on. But I am getting very distracting audible clicks - only with that module. Other VCOs are just fine.
Today I got a Fundamental update to v2.02, not sure if that has any bearing on the issue.
Here is a picture of the frequency spectrum that shows a lot of noise, above a relatively clean VCV VCO spectrum for comparison. The clicks are bad enough that I really can’t use the WT VCO.
I Iogged a bug that if you adjust the wavetable size while it’s running that you get a lot of distortion until you quit and re-load. But I don’t think you are doing that.
Looking at your spectrum, that noise is not super loud, like maybe -48 db?
How often are you hearing the clicks? I have to confess I have not tried this module with my ears yet.
If I set the analyzer for 96 db then I see a little junk way down there, but that’s not much junk at all. Here I’m comparing with with the “pure sin” output from my BasicVCO, which is awfully clean, but as you can see there are things going on really low with both of them. As well as that distinctive frequency spreading (or shoulders). I’ve never been able to get rid of that. I think it might be phase jitter, but I don’t know.
I think it may have something to do with the new mutex that was added in Fundamental WTVCO 2.02:
I’m still studying that code to learn more how it works, but adding a DEBUG("***") in that if statement was showing that the lock can not be gotten a couple of times per a few seconds or so, and I did the exact same test with the spectrum analyser and saw those very low spikes that you show. Perhaps in Dave’s setup, for an unknown reason, that mutex lock is failing more often, hence the harmonics being added.
When the lock fails, the process returns and the output is kept at the same value as in the previous sample. In my test the effect was inaudible, but I could see the difference when compared to the Fundamental VCO (the non WT one).
For any devs following this and that are more knowlegeable than me, I’m very curious to learn what role the mutex plays and why it is needed in Andrew’s december 24th commit on this (other than the commit message of course).
edit : This was most likely a red herring. Looks like the audio glitching is simply because the mutex is locked when the waveform data is drawn into the GUI.
In case anyone is concerned, that relatively high CPU usage in my video is due to the fact I had a much larger patch below, off-screen. I get the same result with a minimal patch showing 4% avg, 12% max CPU.
OOH! I must look into this. it smells right - I’m on win11 and not getting it. sounds random… like threads… oh - and I didn’t download that update yet!! updated - now I hear it!!!
tricky stuff, but @marc_boule 's theory sounds valid - if process can’t generate a sample something bad happens? But it would seem it would just continue to output the last value. I sure can’t exactly figure out that’s going on. It sounds like a tricky problem and it’s not clear why this solution doesn’t work.
Just judging from the name - I don’t think I’d want to run “interpolate” while that data is playing!
It’s not at all clear, even it this locking isn’t right, why anyone would be “updating” the wave table when you aren’t touching it… Some kind of slewing as the controls settle down? In any event, I’ll bet @Vortico can fix this before I can figure it out
now that I got the update and hear the clicks, yes, the spectrum does “go wonky” when it clicks. Just looking at it I thought that was the steady state, but I think you took the screen capture when it made the noise? In any case, yeah, I see something in the same universe now, for sure.
The bug (at least the one I am hearing here on Mac Os 10.13) is definitely due to the use of the mutex in the module process() method. I simply commented out the lines :
if (!wavetable.mutex.try_lock())
return;
DEFER({wavetable.mutex.unlock();});
And the clicking sound went away. (edit : this obviously reintroduces whatever bug or bugs the use of the mutex was intended to solve.)
@marc_boule 's theory is more to the point - leaving early from process is very suspicious. There’s not reason to think using a variable wouldn’t do the same thing as a mutex. The theory most of us have is that leaving process without generating anything is suspicious.
@marc_boule : aren’t those updates initiated on the audio thread in the first place? Like if a parameter change happens, the audio thread sees it, then locks itself out of the processing? That would mean no audio could get updated at all until the interpolate is finished.
wait - even it it was a third thread - you still couldn’t update the audio until the full interpolate is done - so this has to pop a ton, right??
You are nicer than me - you do it Your existing write up is more than enough for a bug. In fact the repro is merely: put in a WVCO, don’t change anything. listen to the output pop.
Your existing write up is more than enough for a bug. In fact the repro is merely: put in a WVCO, don’t change anything. listen to the output pop.