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

wine-bugs at winehq.org wine-bugs at winehq.org
Tue Oct 14 05:01:17 CDT 2008


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





--- Comment #16 from Jörg Höhle <hoehle at users.sourceforge.net>  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?


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.


More information about the wine-bugs mailing list