Matteo Bruni (@Mystral) commented about dlls/dsound/mixer.c:
- int fir_used = (fir_len - 1 - idx + dsbfirstep - 1) / dsbfirstep; + UINT idx_num = (freq_adjust_num - 1 - opos_num % freq_adjust_num) * fir_step; + UINT idx = idx_num / freq_adjust_num; + float rem = idx_num % freq_adjust_num / (float)freq_adjust_num;
- int j; - float sum = 0.0; - float* cache = &input[ipos]; - - for (j = 0; j < fir_used; j++) - sum += (fir[idx + j * dsbfirstep] * (1.0f - rem) + fir[idx + j * dsbfirstep + 1] * rem) * cache[j]; - output[i] = sum * firgain; + UINT i; + for (i = 0; i < fir_width; ++i) + output[opos + i] += (fir[idx + i * fir_step] * (1.0f - rem) + fir[idx + i * fir_step + 1] * rem) * input[j] * firgain;
This patch isn't changing much functionally (I think?), but the existing approach of "unbounded stretching" of the filter seems a bit sketchy to me and this change depends on it (it's "hardcoding" that assumption). IIUC that stretching effectively raises the filter's cutoff frequency to the buffer's frequency, which can become too high for the mixing sample rate and thus introduce aliasing. As I remember, other resamplers usually limit the scaling to some maximum amount to avoid this kind of issue. I guess in practice this is going to be a somewhat exotic case (e.g. nowadays downsampling is probably rarer than upsampling to begin with, also the highest sample rate is bounded at `DSBFREQUENCY_MAX`) but I'm a bit wary of hardcoding it in this way. As I understand it, this is a very important piece of the whole optimization idea and I might be misinterpreting things, so I'm certainly interested in hearing from you. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10255#note_131742