- Wine-gitlab - list.winehq.org

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

12 Jan '26

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 (＠rbernon) 12 Jan '26

12 Jan '26

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

3 3

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

12 Jan '26

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) 12 Jan '26

12 Jan '26

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) 12 Jan '26

12 Jan '26

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) 12 Jan '26

12 Jan '26

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 11 Jan '26

11 Jan '26

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 v10 0/11] MR9628: Implement pointer input APIs for multi-touch support
by Hecheng Yu (＠kde-yyds) 10 Jan '26

10 Jan '26

These patches implemeted core pointer input APIs required by modern applications with touchscreen support, particularly Chromium and Qt-based applications. Implemented APIs: - GetPointerType: Query pointer input type (touch, pen, mouse) - GetPointerTouchInfo: Retrieve detailed touch pointer information - GetPointerFrameTouchInfo: Get all active touch pointers in current frame Added stubs: - SkipPointerFrameMessages: Used by applications to skip pointer frame processing like Qt - GetPointerFrameTouchInfoHistory: Historical touch frame data (not yet implemented) - GetPointerPenInfoHistory: Historical pen data (not yet implemented) System metrics changes: - SM_DIGITIZER: Reports touch capabilities (NID_INTEGRATED_TOUCH | NID_MULTI_INPUT | NID_READY) - SM_MAXIMUMTOUCHES: Returns maximum simultaneous touch points (10) Limitations: - We explictly set pointer type to PT_TOUCH when storing pointer info to queue, so GetPointerType will always return PT_TOUCH - GetPointerFrameTouchInfo returns 0 pointers after finger lift, while Windows returns 1 pointer with UP flags. And SkipPointerFrameMessages is currently a stub returning TRUE. Qt's pointer message processing uses both of them, but it's just working well Application requirements: - Chromium: Requires GetPointerType and GetPointerTouchInfo for touch input - Qt applications: Need GetPointerFrameTouchInfo and proper system metrics for multi-touch support - Qt5: Additionally checks for presence of all pointer APIs at runtime, requiring stubs to enable pointer messages processing -- v10: user32: Implement GetPointerFrameTouchInfo win32u: Implement NtUserGetPointerFrameTouchInfo user32: Implement GetPointerTouchInfo win32u: Implement NtUserGetPointerTouchInfo user32: Implement GetPointerType win32u: Implement NtUserGetPointerType win32u: Add pointer information cache and storage user32: Stub GetPointerPenInfoHistory user32: Stub GetPointerFrameTouchInfoHistory user32: Stub SkipPointerFrameMessages win32u: Add SM_DIGITIZER and SM_MAXIMUMTOUCHES system metrics https://gitlab.winehq.org/wine/wine/-/merge_requests/9628

3 13

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

10 Jan '26

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

[PATCH v4 0/1] MR9858: qasf: Fix use-after-free of filter in reader callback.
by Yuxuan Shui (＠yshui) 10 Jan '26

10 Jan '26

If a asf reader callback is invoked after its corresponding reader has been destroyed, it will still try to use the reader via asf_callback->filter, resulting in use-after-free. This commits sets asf_callback->filter to NULL when the reader is destroyed, and adds NULL checks to reader callback functions to make them no-op after the reader is destroyed. Fixes: Bug 59159 -- v4: qasf: Stop the WMReader first in asf_reader_destroy. https://gitlab.winehq.org/wine/wine/-/merge_requests/9858

3 8