Possible bug in NVDSP.mm when copying the results back to audio buffer

[bartolsthoorn]

Possible bug in NVDSP.mm when copying the results back to audio buffer

[bartolsthoorn]

It has been a long time since I last touched that part of the code, but I think what you are looking for is this: NVDSP.mm#L75
So in fact, the buffer is copied starting from the 3rd index, just like your line does, using &(tInputBuffer[2]). The code in NVDSP is presented in a different way than the page you mentioned, but operates in a similar way. Each time, 2 samples are stored to ensure a smooth transition between buffers. An error in this process will immediately lead to noticeable distortion. The buffers are very short, and without handling trailing/leading samples correctly, a fast "clicking" distortion will be introduced at each new buffer that calls filterContiguousData.
I will close this for now, but please correct me if I am wrong and definitely let me know if you do hear any distortion caused by the problem you mentioned.

[crontab]

Strangely, there is no difference in audio either way, with or without +2! But I believe the way vDSP_deq22() works is, the output data start at +2. A lot of examples on the Internet confirm that.

[bartolsthoorn]

Hmm, even the official API states "This function creates N new values in output vector C, beginning with its third element." - apple_ref/c/func/vDSP_deq22

I looked into it and I think the only difference is that NVDSP outputs the first two samples (in gInputKeepBuffer) the very first time, but after that it does not matter (in practice) whether you output +2, because the buffer start/end still connect perfectly. If this is true, NVDSP introduces a 2-sample delay though, which is what I will look for now. I will do some testing and let you know what I find. I will ask you to make a merge request if you want to - for the Github love.

[bartolsthoorn]

@crontab Tested it, and you were right, using the +2 is slightly better, it prevents the 2 samples delay and leads to the same audio. Could you make a merge request with the new line?

memcpy(data, tOutputBuffer + 2, numFrames * sizeof(float));