[Bug 14717] resampled sound is horrible

wine-bugs at winehq.org wine-bugs at winehq.org
Sat Nov 27 06:32:21 CST 2010


--- Comment #26 from Krzysztof Nikiel <zzdz2 at 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.

Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.

More information about the wine-bugs mailing list