http://bugs.winehq.org/show_bug.cgi?id=14717
--- Comment #26 from Krzysztof Nikiel zzdz2@yahoo.pl 2010-11-27 06:32:20 CST --- (In reply to comment #23)
As for the code itself:
You are using a reference-counted buffer for the FIR. This can work only if you guarantee that all the callers for FIR creation and destruction are in the same thread. Otherwise, you can attempt to generate two FIRs concurrently. If thread safety is indeed an issue, I'd suggest just dumping the coefficients into a static array in a header file.
Right, another bug, thanks. IIRC there are some special functions like EnterCriticalSection to get the process mutex so this can be solver easily.
As for my earlier remark about the cutoff frequency in your code, I missed the "cutoff = stopstart * resamp_ratio - (widthfac0 / FIR.width)" that explains it all. Still, your FIR is shorter even than the "fastest" option in libsamplerate. Libsamplerate seems to use a simple Gaussian window, maybe that's the reason that you don't need such a long FIR.
IIRC, i compared different windows in the past and Kaiser looked pretty good. Wikipedia has some nice article about these windows but i would say Gaussian doesn't look better than Kaiser. Note that mp3 format uses even worse hanning windows.
About my earlier remark about buffer overflows: I found no such things in your code, but it looks like the guard value that you allocated "just in case" at the end of the FIR is sometimes accessed. I may be wrong, though. I know I shouldn't review code at night :)
Oh, i'm pretty sure those bytes are unused but i may be wrong. May be better remove them to avoid confusion.