[Bug 12349] New: DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb->tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

Summary: DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <=
                    dsb->tmp_buffer_len' failed
           Product: Wine
           Version: 0.9.57.
          Platform: PC
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: directx-dsound
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

Hi,

at least two applications regularly abort because of this assertion failure.
"Der Löwe ist los" and "Tiger Team - Geheimnis der goldenen Mumie"
 (games for children, from different German editors).

A common point is that both are based on Macromedia. During run they create a
folder in windows/temp/ containing msvcrt.dll, iml32.dll (containing the string
Macromedia Director 7.0.2r85 1999), dirapi.dll and xtras/*.x32.
I.e. Macromedia might badly drive dsound. That might be the culprit.

The applications basically start, however at random time, they abort with the
message:

err:dsound:DSOUND_MixInBuffer length not a multiple of block size, len = 1579,
block size = 2
mixer.c:489: DSOUND_MixInBuffer: Assertion `dsb->buf_mixpos + len <=
dsb->tmp_buffer_len' failed.

I've tried WINEDEBUG=dsound which overflows me with endless output. I'll try to
extract a sensible snippet and attach it.

I'm using 0.9.57 (compiled locally) with Ubuntu Dapper & Gutsy, ALSA output.

Note that some of the sounds are played very well, others produce (very loud)
noise. At some point in time, the application aborts.

A possibly related (revealing?) issue is that I could "turn" a broken sound
(producing loud noise and often causing the assertion failure) into its audible
form by clicking on another object in the game "Tiger Team". This causes some
good speech output, and while speech goes on, click the initial object: the two
sounds are mixed correctly.

This item might be related to bug #7693, yet that one only talks about the
error log message, not the application aborting because of the assertion
failure.

Regards

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb-> tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

Maarten Lankhorst  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #1 from Maarten Lankhorst   2008-04-03 12:23:25 ---
Can you test wine v0.9.58 please?

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb-> tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

--- Comment #2 from Jörg Höhle   2008-04-04 05:43:48 ---
Fix heap off by one error as "for (i = 0; i < len; i+=2)" loops once
with len=1 even though it must not.
This is exactly what happened in this trace (with 16 bits per sample):
trace:dsound:DSOUND_MixerVol (0x1359528,2048)
trace:dsound:DSOUND_MixerVol (0x1359528,2050)
Program ran was fine as long as len was a multiple of 4, not just 2.

This patch code is put under the same copyright as wine as of version
0.9.58, c.f. src/git/wine/{LICENSE,COPYING.LIB}

2008-04-03  Jörg Höhle

* dlls/dsound/mixer.c:
        dound: fix heap off by one overflow in DSOUND_MixerVol.

--- dlls/dsound/mixer.c.orig    2008-01-17 10:14:34.000000000 +0100
+++ dlls/dsound/mixer.c         2008-04-03 22:26:33.000000000 +0200
@@ -444,7 +444,7 @@
        case 8:
                /* 8-bit WAV is unsigned, but we need to operate */
                /* on signed data for this to work properly */
-               for (i = 0; i < len; i+=2) {
+               for (i = 1; i < len; i+=2) {
                        *(bpc++) = (((*(mem++) - 128) * vLeft) >> 16) + 128;
                        *(bpc++) = (((*(mem++) - 128) * vRight) >> 16) + 128;
                }
@@ -453,7 +453,7 @@
                break;
        case 16:
                /* 16-bit WAV is signed -- much better */
-               for (i = 0; i < len; i += 4) {
+               for (i = 3; i < len; i += 4) {
                        *(bps++) = (*(mems++) * vLeft) >> 16;
                        *(bps++) = (*(mems++) * vRight) >> 16;
                }

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb-> tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

--- Comment #3 from Jörg Höhle   2008-04-04 05:51:00 ---
Although the above bug fix does not immediately seem related to the MixInBuffer
assertion failure, I haven't observed it any more in Tiger Team1. I have
not yet had the opportunity to test the other game.

What I've noticed now, with no more aborts, is that sound is not perfect yet.

For one, the QuickTime (4.0) player is to blame (which Tiger Team1 installs),
as seen by comparing it with xine.  Both display a .mov file at
the same speed, but the sound from the .mov lags behind in wine, and
the end is simply cut off.  The more I'm tracing (e.g. WINEDEBUG=dsound),
the more is cut off the end.  There's also a slight stuttering audible
in voice output, not music, even though there's no mention of a
buffer underrun in dsound. Well, perhaps cut off is preferable to skipping
sound (like dropping video frames) amid the playback.

The other problem still remaining is that some sound samples are
played well, while others produce noise.  Often repeatably, c.f. the
previously mentioned trick with mixing two sounds to have the second one
become audible. I believe I need to turn this into a distinct bug report.

I've not had an opportunity to test 0.9.58 yet. However, my patch applies
cleanly in a 0.9.58 build, i.e. this heap overflow bug is also in 0.9.58.

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb-> tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

--- Comment #4 from Maarten Lankhorst   2008-04-04 06:00:43 ---
I would rather change the stop condition, because it is more intuitive.

for (i = 0; i < len-1; i += 2)
and for (i = 0; i < len-2; i += 4)

Mixing a single byte doesn't make sense if your shortest unit of data is 2
bytes long so I put len-2 instead of len-3. Nonetheless I have various checks
that make sure samples are aligned with the amount of channels.

Nice catch. Can you submit the fixed version to the wine-patches mailing list?

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb-> tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

--- Comment #5 from Jörg Höhle   2008-04-04 07:33:47 ---
> > for (i = 1; i < len;   i += 2)
>
> for (i = 0; i < len-1; i += 2)

Please pardon my micro-optimizations.
> for (i = 0; i < len-2; i += 4)
> Mixing a single byte doesn't make sense if your shortest unit of data is 2
> bytes long so I put len-2 instead of len-3. Nonetheless I have various checks
> that make sure samples are aligned with the amount of channels.

I had not seen such checks (probably in other functions).

But do you have a check to ensure that len is aligned on the bitpersample size?
That's precisely why I used 3 and not 2 even 2 sounds logical in context. Some
bogus application could call with len = 3 or 1027 with 1 channel a 16bits. 
Then the -2 code overflows, while the -3 doesn't. Of course, if you can proove
that somewhere up in the call hierarchy, this can never happen, we need not
discuss this further.
> Can you submit the fixed version to the wine-patches mailing list?

Luckily, http://winehq.org/site/forums says this is an open list, so I'll do.

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb-> tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

--- Comment #6 from Maarten Lankhorst   2008-04-04 12:44:05 ---
I'm reasonably sure that the mixing function does the align check, hence the
ERR you're getting..

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb-> tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

--- Comment #7 from Jörg Höhle   2008-04-14 10:01:20 ---
Patch submitted to wine-patches.
For the record, Maarten suggested to use "-2" in the second check, because len
is always even. I argue that -3 is always safe and appropriate (for a loop that
writes 4 bytes at a time) and does not require an extra comment to explain that
-2 is good enough in this particular case. So I submitted it with i<len-3.
Feel free to apply any modifications before you git-commit, I won't take
offense.

Given time, I'll try and find out more about the other issue: noise vs.
well-played sound samples.

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb-> tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

Jörg Höhle  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|0.9.57.                     |0.9.60

--- Comment #8 from Jörg Höhle   2008-04-26 09:24:42 ---
I now tested the other application, "Der Löwe ist los", now using 0.9.60.
Alas, my patch does not make the assertion error disappear completely.
The good news is that it has become very rare now.

I'm attaching a +dsound trace of a crash. It shows how the error "length not a
multiple of block size" in MixInBuffer appears in the penultimate invocation of
this function, i.e. the crash happens on the next iteration after this message.

Maybe even the length capping is related to the problem, as the end is not
reached as expected??

winecfg says ALSA, 44100Hz 16bits

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb-> tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

--- Comment #9 from Jörg Höhle   2008-04-26 09:27:53 ---
Created an attachment (id=12488)
 --> (http://bugs.winehq.org/attachment.cgi?id=12488)
dsound log with length not a multiple of block size, then assertion failure

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb-> tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

Lei Zhang  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|0.9.60                      |0.9.57.

--- Comment #10 from Lei Zhang   2008-04-26 12:44:07 ---
Please don't change the original reported version.

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb-> tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

--- Comment #11 from Jörg Höhle   2008-05-19 11:04:48 ---
Rethinking comment #4, I found good reasons to prefer
for (i = 3; i < len;   i += 4)
over
for (i = 0; i < len-3; i += 4)
because the former works with both signed and unsigned integer types.
The latter only works reliably with signed integers. Luckily, len and i are
signed (INT), so it's ok here.

With unsigned integers, imagine len were 2, len-3 (=0xffffffff) would defeat
the end test and loop a billion times.

Alas, the patch has not appeared in 0.9.60, .61 nor in 1.0rc1, despite posting
twice to wine-patches. I'll have to find out what's "Not Obviously Correct".

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb->tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

--- Comment #12 from Maarten Lankhorst   2008-06-19 00:07:17 ---
The error is the first clue. For whatever reason the alignment is wrong,
causing horrible problems. Could it be that the secondary buffer has an
alignment of 2 (mono buffer) and the primary of 4?

Also you want to figure out what the exact values of tmp_buffer_len, nAlign,
and buf_mixpos are. They will give some clues what exactly is going on.

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb->tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

--- Comment #13 from Jörg Höhle   2008-06-19 10:14:39 ---
Re comment #12
> Also you want to figure out what the exact values of tmp_buffer_len, nAlign,
> and buf_mixpos are. They will give some clues what exactly is going on.

The log I attached already contained additional traces I added, not found in
the original wine source (maybe I should submit them as regular patches):

trace:dsound:DSOUND_MixInBuffer buf_mixpos=46690/48001 sec_mixpos=21448/44100
trace:dsound:DSOUND_MixInBuffer buf_mixpos=47984/48001 sec_mixpos=22042/44100
trace:dsound:DSOUND_MixInBuffer buf_mixpos=48000/48001 sec_mixpos=22050/44100

nAlign is missing, I'll add that (when I'll be back from holidays).

What always puzzled me: is 48001 a sane value for the size? I understand where
it comes from (rounding issues when calculating / inverting buffer sizes for
resampling from 44100<->48000), but I wonder whether such an odd buffer size
might participate in causing the bug (I.e. it may break the boundary/end of
buffer detection)?

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb->tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

--- Comment #14 from Jörg Höhle   2008-09-17 05:32:37 ---
With 1.1.4, I still obtain reproduceable assertion errors in "der Löwe ist
los": After playing "lion catches the parrot's guano on the island",
immediately after the application moves on to the next scene.

What stuck me now is that approx. 200 hundred loglines before the assertion
failure, wine reports and exception (in the main thread, 0009) and says it's
invoking the debugger. No debugger, no backtrace is seen and wine exits little
later with the assertion failure (in the dsound thread, often 0018).
So the assertion failure may be a side-effect of something else going wrong.
For now I don't even know what that thing is, whether it's related to sound or
not.

Using 0.9.16, I was unable to crash the game, so the issue can be considered a
regression. I tried the same ALSA settings in 1.1.4 as in 0.9.16 (22050Hz, 8
bit). I also tried OSS: same behaviour.

How can I have wine start the debugger immediately in the main thread 0009 (and
print a backtrace), instead of dying in 0018?

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb->tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

--- Comment #15 from Maarten Lankhorst   2008-09-17 07:02:54 ---
You can run the application with the debugger already attached:

wine winedbg application

then 'run'

You might want to change HKCU\Software\Wine\Winedbg and change
BreakOnFirstChance to 0 if too many exceptions occur.

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb->tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

--- Comment #16 from Jörg Höhle   2008-10-14 05:01:17 ---
The state is currently as follows.

Regressions testing the assertion failure in "der Löwe ist los" lead to
commit: cdbd17bdb85a80d62acec036a0314e7343e30d7e
dsound: Make hardware acceleration work again
but that is a dead-end, as I believe something goes wrong long before the
crash. Now that I had an opportunity to compare the behaviour with a w95
machine, I know that the music in the concerned section is played back way to
fast.

While sound output mostly works fine in the application, the section that leads
to the crash is a mini-game that increases the tempo of the music 3-4 times
during play. At the end of this mini-game, after switching to the next section,
the assertion is thrown.

What distinguishes hardware acceleration from the other modes in winecfg?
- HW acceleration plays the music so fast that it sounds like noise, then
crashes.
- Basic and Emulation modes alternate music with pauses, one per second approx.
Sound mixin is not perfect, as the music is too loud and occasional sound
events hardly heard (on the w95 machine, everything mixes well). More
precisely, the occasionally produced sound events are only recognizable during
these "pauses", i.e. the pauses are not completely silent, but their volume is
too low.

My belief is that first the sound mixing should be fixed, then see if the crash
still occurs. Now where to look, what to look for?

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb->tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

--- Comment #17 from Maarten Lankhorst   2008-10-14 08:37:30 ---
Volume too low is a known problem, our implementation doesn't handle volume too
well, and I think it is slightly off. You'll probably want to get the log lines
leading up to the crash. It could be some very small bug, like buf_mixpos not
being reset after a frequency change.

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb->tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

--- Comment #18 from Austin English   2009-04-17 12:11:21 ---
Is this still an issue in current (1.1.19 or newer) wine?

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb->tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

--- Comment #19 from Jörg Höhle   2009-04-21 02:53:13 ---
The assertion failure persists with ALSA in wine-1.1.19 on Ubuntu Hardy.
A difference against my comment #16 is that the driver emulation setting makes
no difference anymore.  The music is always played way too fast, without pauses
but one at the beginning.

What's new is that OSS works perfectly, with or without driver emulation.
+ The music plays nicely,
+ the tempo increases slowly as the lion manures the flower,
+ sounds of the lion's footsteps and the dolphin's voice are correctly mixed
in.

Uhoh, that means I'll have to test the whole app to see whether it deserves
gold rating and provide the missing AppDB entry.

Alas, winecfg doesn't allow per-application choice of ALSA or OSS. Only
subordinate settings like sampling rate seem honoured.

I can provide comparative logs of ALSA and OSS on request.  What WINEDEBUG
settings would be useful? +alsa, +dsalsa?, +oss? What else?

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb->tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

--- Comment #20 from Jörg Höhle   2009-09-02 06:13:54 ---
Oddly, recompiling wine-1.1.19 nowadays after observing the same assertion
failure in bug #19901, I cannot reproduce some of my own findings of comment
#19.

I wrote:
> What's new is that OSS works perfectly, with or without driver emulation.

Now I find that only OSS hardware mode works perfectly in wine-1.1.19 (and the
current 1.1.28).
OSS emulation produces effects like ALSA emulation: they alternate music with
pauses, as mentioned in comment #16.
In summary, what mode works and what not is similar to my observations about
"der Dieb von Burg Schreckenstein" in bug #19901, comment #0.

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb->tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

--- Comment #21 from Jörg Höhle   2009-09-11 08:05:29 ---
Created an attachment (id=23555)
 --> (http://bugs.winehq.org/attachment.cgi?id=23555)
mail to wine-devel incl. patch

It turns out that bug #19901 and this one share a common cause.
Wine gets confused by nBlockAlign or nAvgBytesPerSec being inconsistent (bogus)
with nSamplesPerSec/nBitsPerSample/nChannels.
Please see bug #19901 for further information, because it is less cluttered.

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb->tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

Jörg Höhle  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED

--- Comment #22 from Jörg Höhle   2009-09-17 11:28:17 ---
OSS commit 8870fe38b5d9a143c78c68a43c95c1be766739b3
CoreAudio  commit e6770a40118349e8d33e52a54af3602e9af76ac3
Expect ALSA when I'll have more time.

Is it right to mark this as resolved even though not all audio drivers are
fixed?

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb->tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

--- Comment #23 from Henri Verbeet   2009-09-18 03:41:06 ---
(In reply to comment #22)
> OSS commit 8870fe38b5d9a143c78c68a43c95c1be766739b3
> CoreAudio  commit e6770a40118349e8d33e52a54af3602e9af76ac3
> Expect ALSA when I'll have more time.
>
> Is it right to mark this as resolved even though not all audio drivers are
> fixed?

Probably not.

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb->tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

Jörg Höhle  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|FIXED                       |

--- Comment #24 from Jörg Höhle   2009-09-18 06:05:58 ---
Leaving the bug open until all drivers are fixed.
Open bugs are easier to find to avoid duplicates.

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb->tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

Jörg Höhle  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED

--- Comment #25 from Jörg Höhle   2009-10-06 14:34:00 ---
Fixed by my pre-1.1.31 commit dc3471ca0e7c2209ecf9758359cc62f9d958bf2c
for all audio drivers (ALSA+OSS+CoreAudio+...)

Bot "der Löwe ist los" and "Tiger Team das Geheimnnis der goldenen Mumie" (not
yet in AppDB) are cured. Tiger Team is especially interesting, because it is a
Macromedia/Director application. Perhaps there are many more affected apps?

Gee, when I reported this a year and a half ago, I did not think that I'd ever
fix sound issues myself, given those daunting log files ;-)

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb->tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

Maarten Lankhorst  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #26 from Maarten Lankhorst   2009-10-06 17:08:29 ---
welcome to my world ;)

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb->tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

Nikolay Sivov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CLOSED                      |RESOLVED

--- Comment #27 from Nikolay Sivov   2009-10-06 17:10:14 ---
(In reply to comment #26)
> welcome to my world ;)

Let's wait for release.

[Bug 12349] DSOUND_MixInBuffer Assertion `dsb->buf_mixpos + len <= dsb->tmp_buffer_len' failed

http://bugs.winehq.org/show_bug.cgi?id=12349

Alexandre Julliard  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #28 from Alexandre Julliard   2009-10-09 11:13:38 ---
Closing bugs fixed in 1.1.31.