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