[Bug 56702] New: Resampler cutoff frequency for upsampling seems too low
https://bugs.winehq.org/show_bug.cgi?id=56702 Bug ID: 56702 Summary: Resampler cutoff frequency for upsampling seems too low Product: Wine Version: 9.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dsound Assignee: wine-bugs(a)winehq.org Reporter: ttacwh+fgpjlj0hrlk5k(a)pokemail.net Distribution: --- When you use wine directsound and mix in a secondary buffer whose sample rate is below your device sample rate (for example, upsampling 8000/11025 to 44100/48000), the resampled output has a frequency cutoff at around 1/4 of the secondary buffer's sample rate (1/2 nyquist frequency) instead of where it's supposed to be - around 1/2 the sample rate (or ~85% of nyquist freq, going by make_fir). You can also visually verify this if you view the spectrum of the resampled output. This can be very noticeable especially if your input sounds are of a lower sample rate but still have higher frequencies present. Other related aspects seem to be working correctly (mmdev opening the device at requested sample rate, pulseaudio negotiating sample format correctly according to logs, no other resampling in the chain). It seems that the fir resampler logic (mixer.c, fir.h, make_fir) hasn't substantially changed since it was first added over a decade ago, so this seems less likely to be a regression. Additionally, I confirmed that the linear resampler from DSound-Fast_Mixer patch (from wine-staging) does not have this issue - you can force it to always use the linear resampler by setting HQBuffersMax reg key to 0. I don't have a test case to upload, but it should be fairly simple to reproduce. Tested on wine-devel 9.8 and 9.9 (linux mint 21.3 / ubuntu 22.04) Thanks! -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56702 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Staged patchset| |https://gitlab.winehq.org/w | |ine/wine-staging/-/tree/mas | |ter/patches/dsound-Fast_Mix | |er Ever confirmed|0 |1 Status|UNCONFIRMED |STAGED --- Comment #1 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- Are you aware of any applications affected by this? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56702 --- Comment #2 from ttacwh+fgpjlj0hrlk5k(a)pokemail.net --- Yes, it's an old now-defunct mmo - Asheron's Call (retail servers are no longer up, but there are emulators and the client can still be downloaded). It's also likely that other older apps/games might use lower sampling rate sounds with directsound. The game client itself uses a pretty wide variety of sampling rates for its sounds/secondary buffers (8000/11025 mono for the older sounds all the way up to 44100 stereo for the newer), so it is pretty obvious when lower samplerate sounds get incorrectly resampled. Also, I noticed if you simply double both $approx_bandwidth and $fir_step values (from 0.85/120 to 1.70/240, respectively) and regenerate fir.h with it, that the resulting spectrographs appear more in line with expectations and the resampled audio sounds better as well. Don't take that as a real fix, however, as I'm not an expert in dsp. Not sure if that is actually the correct thing to do or if there's an actual calculation bug in make_fir (or even mixer.c), so I'm hoping someone who knows this stuff well might chime in :) -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56702 --- Comment #3 from ttacwh+fgpjlj0hrlk5k(a)pokemail.net --- Might have misspoke in my last comment - those changes to make_fir actually introduce aliasing. Please ignore that, my apologies. Still messing with it, will update if I have something more to share. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56702 ttacwh+fgpjlj0hrlk5k(a)pokemail.net changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WORKSFORME Status|STAGED |RESOLVED --- Comment #4 from ttacwh+fgpjlj0hrlk5k(a)pokemail.net --- Please ignore this bug - I made a mistake and the dsound resampler works fine. I ended up comparing the spectrograms of the original extracted sounds and recorded sounds (with both the staging patch and without), and the resampler bandpass/bandwidth is correct as per comments in make_fir. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56702 ttacwh+fgpjlj0hrlk5k(a)pokemail.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #5 from ttacwh+fgpjlj0hrlk5k(a)pokemail.net --- Closing the bug -- 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.
https://bugs.winehq.org/show_bug.cgi?id=56702 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|WORKSFORME |INVALID -- 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.
participants (1)
-
WineHQ Bugzilla