On Fri May 2 17:55:41 2025 +0000, Elizabeth Figura wrote:
> > > I guess native is supposed to not block in that case
> >
> > That's a good point. If we have two streams call
> `IMFMediaStream::RequestSample`, then we will process them in sequence
> rather than in parallel. That is, one stream will have to wait for the
> other to receive data (as we block all other streams once the source cs
> is acquired in `source_async_commands_Invoke`).
> >
> > This MR will at least unblock a stream when there is no more data, but
> Windows probably delivers data for the other stream immediately (i.e. it
> can deliver data for one stream, even if the other was already waiting).
> And I believe I recall seeing audio latency in Wine as a result of this.
> From memory, it was a 4K video, so delivery of the video sample took a
> while and as a result the audio fell behind. We should probably look to
> lock the individual streams rather than the entire source when possible.
> Hrm, I didn't think we had a locking problem, but if we do that should
> be fixed, yeah.
I'll have a think about how I can test this. I might be able to craft a file that'll delay one of the streams long enough, that whilst waiting for a sample, I can reliably request and receive a sample on the other.
Thanks for the review.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7824#note_102482
This MR fixes seek in VRChat by copying the sequence of flushes/stop/starts that Windows does.
The order on Windows is:
1. Stop sources;
2. Flush MFTs;
3. Start sources;
4. Request output down the chain of sink inputs;
6. Flush sinks; and
7. Start the clock
This takes place whether we pause before we seek or seek without pause.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7932
The wave format is passed to DirectSoundDevice_CreateSoundBuffer, which
duplicates it including the 1 byte of extra data after the end of the
struct.
--
v3: dsound/tests: Allocate right amount of memory in test_secondary8 (ASan).
https://gitlab.winehq.org/wine/wine/-/merge_requests/7926
Discovered while I was working on ASan support. ASan shadow memory might be placed where the main
image is normally loaded, forcing it to relocate. `virtual_map_module` handles this correctly but
`virtual_map_builtin_module` doesn't.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7962
If `KeUserModeCallback` fails, `ret_ptr` and `ret_len` might be left uninitialized. Since the
returned status isn't checked in `dispatch_win_proc_params`, it can access uninitialized memory.
* * *
One way this could actually happen is if on x86_64 `KeUserModeCallback` returned `STATUS_STACK_OVERFLOW`.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7960
Fixes a specific game's crash on startup.
`d2d_device_context_draw` doesn't accept `D2D_TARGET_UNKNOWN` because `render_target->target.bitmap->rtv` isn't reliably set when calling `ID3D11DeviceContext1_OMSetRenderTargets`. Therefore, we check for that condition and return early.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7959
VxDCall vwin32 service id 0x0010 provides int21 dispatch functionality and
VxDCall vwin32 service id 0x002a provides int41 dispatch functionality.
All of these vwin32 services together with existing service id 0x0029
(for int31/dpmi functionality) have same API, first VxDCall() argument is
value for EAX register and second argument is value for ECX register.
VxDCall vwin32 service id 0x0010 is used by applications in Andrew
Schulman's book Unauthorized Windows 95. For example by CHGDIR for
getting PSP.
--
v2: vwin32.vxd: Add support for VxDCall() 0x0010 and 0x002a services
https://gitlab.winehq.org/wine/wine/-/merge_requests/7906