[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: wine-bugs(a)winehq.org ReportedBy: hoehle(a)users.sourceforge.net 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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 Maarten Lankhorst <m.b.lankhorst(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.b.lankhorst(a)gmail.com --- Comment #1 from Maarten Lankhorst <m.b.lankhorst(a)gmail.com> 2008-04-03 12:23:25 --- Can you test wine v0.9.58 please? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 --- Comment #2 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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 <hoehle(a)users.sourceforge.net> * 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; } -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 --- Comment #3 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 --- Comment #4 from Maarten Lankhorst <m.b.lankhorst(a)gmail.com> 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? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 --- Comment #5 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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.
-- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 --- Comment #6 from Maarten Lankhorst <m.b.lankhorst(a)gmail.com> 2008-04-04 12:44:05 --- I'm reasonably sure that the mixing function does the align check, hence the ERR you're getting.. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 --- Comment #7 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|0.9.57. |0.9.60 --- Comment #8 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 --- Comment #9 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 Lei Zhang <thestig(a)google.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|0.9.60 |0.9.57. --- Comment #10 from Lei Zhang <thestig(a)google.com> 2008-04-26 12:44:07 --- Please don't change the original reported version. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 --- Comment #11 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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". -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 --- Comment #12 from Maarten Lankhorst <m.b.lankhorst(a)gmail.com> 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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 --- Comment #13 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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)? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 --- Comment #14 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 --- Comment #15 from Maarten Lankhorst <m.b.lankhorst(a)gmail.com> 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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 --- Comment #16 from Jörg Höhle <hoehle(a)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.
http://bugs.winehq.org/show_bug.cgi?id=12349 --- Comment #17 from Maarten Lankhorst <m.b.lankhorst(a)gmail.com> 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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 --- Comment #18 from Austin English <austinenglish(a)gmail.com> 2009-04-17 12:11:21 --- Is this still an issue in current (1.1.19 or newer) wine? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 --- Comment #19 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 --- Comment #20 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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.
-- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 --- Comment #21 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED --- Comment #22 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 --- Comment #23 from Henri Verbeet <hverbeet(a)gmail.com> 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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|FIXED | --- Comment #24 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2009-09-18 06:05:58 --- Leaving the bug open until all drivers are fixed. Open bugs are easier to find to avoid duplicates. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED --- Comment #25 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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 ;-) -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 Maarten Lankhorst <m.b.lankhorst(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #26 from Maarten Lankhorst <m.b.lankhorst(a)gmail.com> 2009-10-06 17:08:29 --- welcome to my world ;) -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |RESOLVED --- Comment #27 from Nikolay Sivov <bunglehead(a)gmail.com> 2009-10-06 17:10:14 --- (In reply to comment #26)
welcome to my world ;)
Let's wait for release. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=12349 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #28 from Alexandre Julliard <julliard(a)winehq.org> 2009-10-09 11:13:38 --- Closing bugs fixed in 1.1.31. -- 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.
participants (1)
-
wine-bugs＠winehq.org