This sort of reverts 096da45036. The deadlock
mentioned there is not spelled out in detail, but likely results from the
streaming thread trying to acquire the filter lock while a main thread which
is holding the filter lock waits for the streaming thread to finish. However,
DirectShow documentation (and manual testing) suggests that the correct way
to avoid this problem is simply to never take the filter lock from the
streaming thread. Since we currently don't do this anymore, it should be safe
to reinstate this lock.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It's not safe to hold the filter lock from a streaming thread, and
anyway we aren't protecting anything that needs locking.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This more closely resembles the threading model prescribed by the DirectX SDK
documentation. In particular, the page "Flushing Data" recommends that
IPin::BeginFlush() do the following steps in order:
1. take the filter lock
2. signal the streaming thread to complete
3. take the streaming lock, if necessary
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
For several reasons.
Firstly, the reference clock should still function when the filter is not
running.
Secondly, IDirectSoundBuffer::GetPositions() in practice returns very coarse
positions, both on Windows and on Wine. On my hardware, the resolution is
about 10ms, which, while suitable for the DirectSound renderer and probably
also any video renderers, is nevertheless actually coarser than
GetTickCount().
Thirdly, testing supports that the native DirectSound renderer returns a
timestamp from IReferenceClock::GetTime() that is more accurate than
IDirectSoundBuffer::GetPositions(). In fact, after dumping a large number of
different clock sources, I came to the conclusion that it is probably using
timeGetTime() as a source. On Wine that's identical to GetTickCount(), so we
may as well just delegate directly to the system clock.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Inspired by a patch by Andrew Eikum.
macOS's mach_absolute_time() stops counting when the computer goes to
sleep/suspend/hibernate/etc. However, Windows's GetTickCount() does not
stop counting. mach_continuous_time() matches Windows's behavior.
BSD's CLOCK_MONOTONIC already counts asleep time.
Unfortunately, there is no clock source on Linux which does exactly what
we want. CLOCK_MONOTONIC_RAW is unaffected by NTP adjustment, but like
mach_absolute_time() doesn't keep ticking when the computer is asleep.
CLOCK_BOOTTIME does keep ticking, but it is affected by NTP adjustments.
CLOCK_MONOTONIC has both problems. What's needed is a
CLOCK_BOOTTIME_RAW, which would not be slewed by adjtimex(2) and would
count time spent asleep.
To avoid issues with skew and performance, this patch falls back to
mach_absolute_time() on macOS if mach_continuous_time() is unavailable.
Note that mach_continuous_time() was introduced in macOS 10.12, meaning
that if the minimum version required is less than that, it will be
linked weakly. Therefore we must check that it is nonnull before
attempting to call it.
Signed-off-by: Chip Davis <cdavis@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Jeff Smith <whydoubt@gmail.com>
Signed-off-by: Piotr Caban <piotr@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Windows 10 1507 still deleted it but 1607 no longer does.
Signed-off-by: Francois Gouget <fgouget@free.fr>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Zebediah Figura