This is based on work done by Andrew Eikum. It has been in some form in Proton for the last 4 years.
If server's sampling rate is not 48kHz **DOOM Eternal** will try to set it 48kHz for the streams using the implemented interface. There's a whole class of audio devices that use 44.1kHz sampling rate and at least PulseAudio / PipeWire tends to inherit the value from the hardware to avoid resampling. The value can also be overridden by the user via the audio server's config files.
In such cases, if the interface is not present or stubbed, this results in **audio underruns and noticeable crackling**.
It's easy to test with pipewire-pulse:
```
$ cat /etc/pipewire/pipewire.conf.d/sample-rate.conf
context.properties = {
default.clock.rate = 41100
}
```
With PulseAudio this should be doable via setting `default-sample-rate = 41100` in `/etc/pulse/daemon.conf`.
--
v4: winepulse.drv: Implement set_sample_rate.
mmdevapi: Implement AudioClockAdjustment_SetSampleRate.
mmdevapi: Add stub IAudioClockAdjustment implementation.
mmdevapi/tests: Add more IAudioClock tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5585
If both buffers are DXGI buffers, they can be copied on the GPU. They
are currently transferred to the CPU, copied by the CPU and then
transferred back to the GPU.
Performing a GPU copy produces ~25% faster playback on 4K video.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5979
I believe that using CPP files in core Wine code is not a good idea. But it would be nice to have the option to compile C++ modules. For example, lsteamclient from Proton is written partially in C++.
Based on @rbernon patch.
--
v2: tools/makedep: Allow building modules with C++ sources.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6009
--
v2: win32u: Use the thread input shared memory for NtUserGetGUIThreadInfo.
win32u: Use the thread input shared memory for NtUserGetCursorInfo.
win32u: Use the thread input shared memory for NtUserGetForegroundWindow.
server: Add cursor handle and count to desktop shared memory.
server: Add a foreground flag to the thread input shared memory.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5995
mf/session: Ensure that the command callback does not return without clearing SESSION_FLAG_PENDING_COMMAND.
Leaving SESSION_FLAG_PENDING_COMMAND set results in no more work items being queued by session_submit_command, and even
if they were, callback would return immediately due to a check at the start of the function.
Thus, it is never valid to leave the function without clearing the SESSION_FLAG_PENDING_COMMAND flag.
This case can be hit by SESSION_CMD_START, and leaves the session unable to process any commands.
Fix this by ensuring that SESSION_FLAG_PENDING_COMMAND is always cleared before the command callback returns.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6011
I believe that using CPP files in core Wine code is not a good idea. But it would be nice to have the option to compile C++ modules. For example, lsteamclient from Proton is written partially in C++.
Based on @rbernon patch.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6009
Adds the registry key
HKEY_CURRENT_USER\\Software\\Wine\\Wayland Driver\\rawinput
witch allows mouse raw input. This makes it easier
to calculate the same sensitivity in different games,
use sensitivity calculators, and easily change values
when changing mouse DPI and do not depend on the compositor or OS.
For example, you want to set the sensitivity to half as much,
but sensitivity curves in libinput are more difficult
to calculate than mouse sensitivity in the games.
Implementation of ideas written in the comments: https://gitlab.winehq.org/wine/wine/-/merge_requests/4698
--
v6: winewayland.drv: Add mouse rawinput support
https://gitlab.winehq.org/wine/wine/-/merge_requests/5869
This reverts commit 5c8ea25014f ("ntdll: Use CLOCK_REALTIME_COARSE for
NtQuerySystemTime() if it has sufficient resolution.")
CLOCK_*_COARSE only provides up to 1ms resolution at CONFIG_HZ=1000.
OTOH, there are several ways to get up to 0.5ms resolution on modern
Windows (high resolution waitable timers, NtSetTimerResolution with
0.5ms). This code path therefore has a possibility of behaving worse
than native.
Since COARSE resolution is HZ dependent, this code path only runs if the
kernel is configured with CONFIG_HZ=1000. Most distro ships does not
ship with this. Therefore, this code path is rarely tested, and is more
of a recipe for surprise. If any application rely on fast
NtQuerySystemTime they are likely already broken for majority of Wine
users.
Given the above reason, don't use CLOCK_REALTIME_COARSE. Use
gettimeofday which is internally hooked to CLOCK_REALTIME.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6007
--
v2: comctl32/tests: Add tests for NULL strings with edit control WM_GETTEXT message.
user32: Fail on NULL string in WM_GETTEXT AtoW wrapper.
comctl32: Fail on NULL string for edit control WM_GETTEXT message.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6004