Why would a single badly timed GC cause all input, from that moment forward, to sound distorted?
I would expect a badly timed GC to perhaps cause a gap in the audio, or a single click, or something of that sort. But what I am hearing is that BASSASIO gets into a state where all newly recorded sound is corrupted. And moreover, the corruption takes the form of a steady "vibration" -- it's not due to repeated GCs, it's too even for that.
In that case I agree, if all input from that moment onward is distorted it should NOT really be related to a GC, as that should indeed only result in a single 'gap' or 'hickup'.
So in that case I am also unsure what might cause your effect.
Being honest I hadn't the time to listen yet - will do so...now!
I am prepared to believe that mixed-mode might be the solution -- I mentioned GC in my original post -- but I would like you and/or Ian to have a listen to the bad sound my app starts making, before concluding that it really is a GC issue.
Note sure, if a mixed-mode assembly will really help, as there is still one issue left wven with mixed-mode assemblies:
You can not handle SYNCPROCs in mixed-mode assemblies as well - as a SYNCPROC still MUST call into managed code regardless - so in essence in the end it will be your mixed-mode assembly calling in at least.
Best practice whatsoever might still be to invoke any code in a SYNCPROC async - so that the SYNCPROC itself can return immediately and your invoked C# syncproc code runs independent and in parallel to that.
Anyhow, looking at some of your code - you now call the PushStream like this:
"PushSampleToStream(Sample<float> sample, int lengthSamples)"
So it looks you hand-over the number of samples to push as well.
How do you calculate them?
After listening to your .wav it might be the case, that you are not pushing 'enough' samples from a certain point in time.
So the initial effect might indeed be caused by e.g. a GC - but from that moment on you start pushing too less samples to the ASIOPROC for playback, so that the Output ASIOPROC doesn't have enough sample data as it actually needs.
So how do you calculate the number of samples to push?
Would it be possible (in your code) to compare the AVAILABLE number of samples (in you loop buffer) with the number of samples requested by the Output ASIOPROC?
Maybe the Output ASIOPROC requests more data as available in the loop buffer?