Resetting it results in position discontinuity. With frequent
SetFrequency() calls, this produces audible crackling. The issue
affects pedestrian voices in GTA: San Andreas.
In some situations, "ZUSI 3" has a lot of secondary buffers in the
PLAYING state, but most of these buffers have a really low volume, so
these buffers are multiplied by 0 before mixing (and possibly after
resampling). There can be hundreds of inaudible buffers at the same
time.
In these situations, the dsound mixthread is unable to mix fast enough,
resulting in sound stuttering and generally poor performance.
To resolve this performance issue, skip the mixing (and possibly
resampling) step for all inaudible secondary buffers.
Signed-off-by: Florian Will <florian.will@gmail.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This region of the audio buffer is forbidden to be written to by the
DirectSound specification. The documentation states: "The write cursor
is the point after which it is safe to write data into the buffer. The
block between the play cursor and the write cursor is already committed
to be played, and cannot be changed safely." However, some applications
still do this, which has lead to audio glitches only when using the Wine
DirectSound implementation. Experiments showed that the native DirctSound
implementation will still play the old audio the first time around when the
buffer region gets overwritten. Use an approach of copying the next forbidden
region into a "committed buffer" to add the same behavior to the Wine
implementation.
Out of performance considerations, only copy data to the committed buffer
when we detect that an overwrite is possible (i.e. the current mixing
region of the buffer gets locked).
Signed-off-by: Eduard Permyakov <epermyakov@codeweavers.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Some games may not receive the DSBPN_OFFSETSTOP event and get stuck if
CloseHandle is called immediately after IDirectSoundBuffer::Stop. To
solve this problem, IDirectSoundBuffer::Stop will immediately notify
the DSBPN_OFFSETSTOP event.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=41292
Signed-off-by: Hiroki Awata <castaneai@by.black>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Instead of selecting the nth effect overall and checking whether it matches.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Use a custom DMO to show the interaction between dsound the DMO more clearly,
and add more tests for IDirectSoundBuffer8::GetObjectInPath().
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
