January 2026 - Wine-GitLab - list.winehq.org

[PATCH v8 0/1] MR9868: winewayland: Fix non-square icons with xdg-toplevel-icon protocol.
by Alex Schwartz (＠alexschwartz01) Jan. 12, 2026

Jan. 12, 2026

Currently, it will stop the app that is running that has a non-square icon This PR fixes that -- v8: winewayland: Fix non-square icons with xdg-toplevel-icon protocol. https://gitlab.winehq.org/wine/wine/-/merge_requests/9868

3 5

[PATCH 0/2] MR9875: Implement InterruptTimeBias and use it in RtlQueryUnbiasedInterruptTime.
by Marc-Aurel Zent (＠mzent) Jan. 12, 2026

Jan. 12, 2026

After https://gitlab.winehq.org/wine/wine/-/merge_requests/8916 `RtlQueryUnbiasedInterruptTime` now includes suspend time as well when it shouldn't. This fixes this and also allows other components like winevulkan to use `RtlQueryUnbiasedInterruptTime`, if that kind of tick count is necessary there. Since calculating the bias is relatively expensive, this is done together with the timezone bias update every second in such a way that it can only monotonically increase. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9875

5 8

[PATCH 0/1] MR9872: qasf: Protect against unconnected pins in media_seeking_ChangeCurrent.
by Yuxuan Shui (＠yshui) Jan. 12, 2026

Jan. 12, 2026

Invoking IMediaSeeking_SetPositions on an asf reader with no pins connected crashes. This doesn't happen on native. Found while working on !9858 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9872

3 3

[PATCH 0/1] MR9866: Revert "ntdll: Switch to CLOCK_BOOTTIME for monotonic counters when available."
by Rémi Bernon Jan. 12, 2026

Jan. 12, 2026

This reverts commit 3d373e452388b60bea9dca6d5c4cf3f8b20a0c54. CLOCK_MONOTONIC_RAW is used in vulkan to correlate QPC timestamps, and there's no equivalent of CLOCK_BOOTTIME there. Using CLOCK_BOOTTIME for QPC breaks the vulkan side with no proper way to fix it. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9866

2 3

Re: [PATCH v2 0/5] MR9588: dsound: Introduce a cubic spline interpolation resampler.
by Matteo Bruni (＠Mystral) Jan. 12, 2026

Jan. 12, 2026

On Mon Jan 12 10:50:32 2026 +0000, Anton Baskanov wrote: > Thanks for the detailed explanation. > > Otherwise we could bring in the sinc resampler, which is theoretically > very solid and still quite a bit faster than the old FIR resampler. > I studied the code of the openal-soft sinc resampler, and I think that > our resampler is theoretically better: > - Our upsampling window width is 65.89 samples, which is much wider than > openal-soft's 24. This should result in a sharper pass-band to stop-band > transition, which means less aliasing. > - openal-soft's downsampling window is limited to 48 samples, whereas we > don’t have such a limit. > - The way openal-soft expands the upsampling window by linearly > interpolating between windows of different sizes is a bit questionable. > We expand the window by varying `dsbfirstep`, which should provide a > smoother transition. > > The FIR resampler used a fixed Gaussian window instead of the > parametrized Kaiser that's customarily used for audio resampling. > It shouldn't be too hard to change the window function in `make_fir`. > > Additionally, the position computation (`total_fir_steps`, `rem`) > using floats wasn't exact, which in turn caused some mid-high frequency distortion. > This can be easily fixed by using integer arithmetic: > <details> > <summary>Click to expand</summary> > ```diff > diff --git a/dlls/dsound/mixer.c b/dlls/dsound/mixer.c > index b50d9f3a8c8..fe1c8a70db3 100644 > --- a/dlls/dsound/mixer.c > +++ b/dlls/dsound/mixer.c > @@ -365,12 +365,12 @@ static UINT > cp_fields_resample(IDirectSoundBufferImpl *dsb, UINT count, LONG64 * > } > > for(i = 0; i < count; ++i) { > - UINT int_fir_steps = (freqAcc_start + i * dsb->freqAdjustNum) * > dsbfirstep / dsb->freqAdjustDen; > - float total_fir_steps = (freqAcc_start + i * > dsb->freqAdjustNum) * dsbfirstep / (float)dsb->freqAdjustDen; > + LONG64 fir_steps_num = (freqAcc_start + i * dsb->freqAdjustNum) > * dsbfirstep; > + UINT int_fir_steps = fir_steps_num / dsb->freqAdjustDen; > UINT ipos = int_fir_steps / dsbfirstep; > > UINT idx = (ipos + 1) * dsbfirstep - int_fir_steps - 1; > - float rem = int_fir_steps + 1.0 - total_fir_steps; > + float rem = 1.0 - (fir_steps_num - int_fir_steps * > dsb->freqAdjustDen) / (float)dsb->freqAdjustDen; > > int fir_used = 0; > while (idx < fir_len - 1) { > ``` > </details> > I also did some experiments, and I was able to make our resampler 5 > times faster without sacrificing the quality by rearranging the FIR > array and using SSE. Maybe we should give it a try. I'll try to come up > with a draft MR. I'm curious about your changes. All things being equal it would be preferable to improve the existing resampler rather than introducing a different one. The problem is that I'm not sure we can make it fast enough without effectively rewriting it from scratch. When I wrote this MR I felt like the current resampler might be hopelessly too complex for realtime resampling of 100+ sound buffers (which is what Fallout 3 and New Vegas can end up with on occasion). I benchmarked Wine's dsound resampling and compared the performance to Windows. I also tested plugging resamplers from other common libraries (speexdsp and libsamplerate, before openal-soft) into Wine's dsound, and that kinda reinforced my view. The fastest fsinc implementation I tried (which is from openal-soft) is still about half as fast as Win 10 / 11's, IIRC. I can go look at the actual numbers but I'm pretty sure a 5x improvement when using explicit SSE does not quite cut it. I'll mention that, since I wrote this MR, I have prepared a few more patches to improve on other pieces of the dsound mixer, which become the bottleneck once the resampler itself gets fast enough. You can find it at https://gitlab.winehq.org/Mystral/wine/-/commits/dsound-perf (I cleaned the patches up locally since I pushed all that to gitlab, but the gist should be there already). For reference, these are the changes: - Prepare all the input samples and store all the generated output samples in one go instead of doing it sample-by-sample - Don't use indirect function calls for sample conversion - Don't use indirect function calls for channel interleaving - Interleave channels after mixing - Mix and apply volume at the same time - SSE mixing These patches give some incremental performance improvements. It's possible that the combination of these and an improved version of the current resampler gets us where we want, although I'm not super hopeful... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9588#note_126630

1 0

Re: [PATCH v2 0/5] MR9588: dsound: Introduce a cubic spline interpolation resampler.
by Anton Baskanov (＠baskanov) Jan. 12, 2026

Jan. 12, 2026

On Mon Jan 12 10:50:32 2026 +0000, Matteo Bruni wrote: > I should have mentioned it together with a few more things, but I forgot > :sweat_smile: > This is basically a C port of the default resampler from openal-soft. > It's MUCH faster while not being much worse in theoretical quality > compared to the old FIR resampler. In practice the old resampler had a > couple of shortcomings that lowered the effective quality[*], so I don't > think this is much a downgrade quality-wise. > Otherwise we could bring in the sinc resampler, which is theoretically > very solid and still quite a bit faster than the old FIR resampler. It > is sensibly slower than this one though, and slower than Windows 10 / 11 > dsound's resampler. I'm not opposed to having it as an option; I did in > fact try to make the surrounding code somewhat generic to facilitate that. > The SSE2 version gives about a 2x speedup for me. For the records it > makes even more of a difference in openal-soft, most likely because we > start running into performance limitations in our dsound outside of the > resampler proper; I should have a few more patches to improve on that. > The SSE2 version is effectively always enabled on (x86) 64-bit. To > compile the SSE2 version on 32-bit you need to have `-msse2` in > `i386_CFLAGS`, or some other option that includes it (e.g. the typical > `-march=nocona` will do that). > [*]: The FIR resampler used a fixed Gaussian window instead of the > parametrized Kaiser that's customarily used for audio resampling. That > can introduce some aliasing or some distortion depending on the input > signal. Additionally, the position computation (`total_fir_steps`, > `rem`) using floats wasn't exact, which in turn caused some mid-high > frequency distortion. In fact I had originally preserved it when porting > the cubic resampler and I did see the same kind of distortion in the new > output, so I ended up using fixed point for that, which is also what > openal-soft does. Thanks for the detailed explanation. > Otherwise we could bring in the sinc resampler, which is theoretically very solid and still quite a bit faster than the old FIR resampler. I studied the code of the openal-soft sinc resampler, and I think that our resampler is theoretically better: - Our upsampling window width is 65.89 samples, which is much wider than openal-soft's 24. This should result in a sharper pass-band to stop-band transition, which means less aliasing. - openal-soft's downsampling window is limited to 48 samples, whereas we don’t have such a limit. - The way openal-soft expands the upsampling window by linearly interpolating between windows of different sizes is a bit questionable. We expand the window by varying `dsbfirstep`, which should provide a smoother transition. > The FIR resampler used a fixed Gaussian window instead of the parametrized Kaiser that's customarily used for audio resampling. It shouldn't be too hard to change the window function in `make_fir`. > Additionally, the position computation (`total_fir_steps`, `rem`) using floats wasn't exact, which in turn caused some mid-high frequency distortion. This can be easily fixed by using integer arithmetic: <details> <summary>Click to expand</summary> ```diff diff --git a/dlls/dsound/mixer.c b/dlls/dsound/mixer.c index b50d9f3a8c8..fe1c8a70db3 100644 --- a/dlls/dsound/mixer.c +++ b/dlls/dsound/mixer.c @@ -365,12 +365,12 @@ static UINT cp_fields_resample(IDirectSoundBufferImpl *dsb, UINT count, LONG64 * } for(i = 0; i < count; ++i) { - UINT int_fir_steps = (freqAcc_start + i * dsb->freqAdjustNum) * dsbfirstep / dsb->freqAdjustDen; - float total_fir_steps = (freqAcc_start + i * dsb->freqAdjustNum) * dsbfirstep / (float)dsb->freqAdjustDen; + LONG64 fir_steps_num = (freqAcc_start + i * dsb->freqAdjustNum) * dsbfirstep; + UINT int_fir_steps = fir_steps_num / dsb->freqAdjustDen; UINT ipos = int_fir_steps / dsbfirstep; UINT idx = (ipos + 1) * dsbfirstep - int_fir_steps - 1; - float rem = int_fir_steps + 1.0 - total_fir_steps; + float rem = 1.0 - (fir_steps_num - int_fir_steps * dsb->freqAdjustDen) / (float)dsb->freqAdjustDen; int fir_used = 0; while (idx < fir_len - 1) { ``` </details> I also did some experiments, and I was able to make our resampler 5 times faster without sacrificing the quality by rearranging the FIR array and using SSE. Maybe we should give it a try. I'll try to come up with a draft MR. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9588#note_126626

1 0

[PATCH v5 0/5] MR9646: mf/tests: Scrubbing tests
by Brendan McGrath (＠redmcg) Jan. 11, 2026

Jan. 11, 2026

This MR adds tests for how scrubbing and rate changes work within the Media Session. -- v5: mf/tests: Check that Rate change in PLAY state is ignored. mf/tests: Test that there is no pre-roll during scrubbing. https://gitlab.winehq.org/wine/wine/-/merge_requests/9646

2 6

[PATCH v4 0/5] MR9646: Draft: mf/tests: Scrubbing tests
by Brendan McGrath (＠redmcg) Jan. 11, 2026

Jan. 11, 2026

This MR adds tests for how scrubbing and rate changes work within the Media Session. -- v4: mf/tests: Check that Rate change in PLAY state is ignored. mf/tests: Test that there is no pre-roll during scrubbing. mf/tests: Fix leaks in test source. mf/tests: Add ClockStateSink to test media sink. mf/tests: Modify test_seek_clock_sink to be ref counted. https://gitlab.winehq.org/wine/wine/-/merge_requests/9646

2 7

[PATCH 0/1] MR4709: winedbg: Show all loaded modules in automatic backtrace.
by Bernhard Übelacker Jan. 10, 2026

Jan. 10, 2026

This patch should change the module list in the automatic backtraces from "info share" to "info wow share". That way all loaded modules should get listed instead of just the process native ones. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4709

3 5

[PATCH 0/1] MR9861: ntdll/unix/file.c: added new xattr for marking directories as readonly
by Rayan Halder (＠rayanh) Jan. 10, 2026

Jan. 10, 2026

On Windows, directories marked as readonly do not behave as readonly directories on linux. Readonly has no effect on windows but on querying for attributes, windows shows the directory to be readonly. To simulate this behaviour, an xattribute is being used to mark a directory as readonly. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50772 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9861

3 7