[Bug 14717] resampled sound is horrible

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=14717

--- Comment #264 from Andrew Eikum <aeikum at codeweavers.com> 2012-01-04 07:12:36 CST ---
(In reply to comment #262)
> Didn't you identify the need for 2->6 in bug #26233, comment #9?

Sorry, I should have been more clear. In the case of n -> m, it will take the
first 2 input channels and map them to the first 2 output channels, leaving the
remaining (n-2) and (m-2) channels unused. This is how the current code works,
but only for the couple cases I listed.

(In reply to comment #263)
> As for the patch, I think I have found a theoretical problem. Your
> X_speex_resampler_get_required_input_length() function can cause the resampler
> to return less than count samples because it rounds down. So, for 11025 ->
> 48000 Hz conversion, if count happens to be 1 for some odd reason, it can
> return 0 and nothing will be converted, leading to an infinite loop. So please
> make absolutely sure that speex cannot request 0 samples. And for safety and
> for simplification of the accounting, I'd even make it always return count
> samples by supplying enough input, even if the secondary stream ends here (i.e.
> pad it with zeros in this case instead of truncating total_length).
> 

Padding with zeroes instead of truncating is a great idea. I'll do that in the
next patchset.

> Since Speex converts until either the input or the output buffer space runs
> out, for the reason above, I think it would be better to add a ceil() to the
> X_speex_resampler_get_required_input_length() function. Or rewrite it using
> fixed-point math to avoid the rounding issues, as shown below (completely
> untested, and the standard coffee warning applies):
> 
> spx_uint32_t X_speex_resampler_get_required_input_length(SpeexResamplerState
> *st, spx_uint32_t out_len)
> {
>     spx_uint32_t ret = out_len * st->num_rate;
>     ret = (ret + st->den_rate - 1) / st->den_rate;
>     return ret + st->filt_len;
> }
> 
> Note that I have changed in_rate and out_rate with num_rate and den_rate,
> because speex might choose to round the resampling factor to a more convenient
> fraction.
> 

Makes sense. I'll use your code.

> Regarding your statement about GTA:SA and Darwinia calling _SetFrequency() with
> unusual values, I have an additional question: do they do that while the stream
> is playing?
> 

Yes. Highway Patrol does as well, to simulate the car engine revving.

-- 
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.