November 2012 - Wine-bugs - list.winehq.org

[Bug 21655] New: MacOS: broken mixing in dsound8 tests + assertion failure
by wine-bugs＠winehq.org 15 Mar '13

15 Mar '13

http://bugs.winehq.org/show_bug.cgi?id=21655 Summary: MacOS: broken mixing in dsound8 tests + assertion failure Product: Wine Version: 1.1.38 Platform: x86 OS/Version: Mac OS X 10.5 Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-dsound AssignedTo: wine-bugs(a)winehq.org ReportedBy: hoehle(a)users.sourceforge.net Must set WINETEST_INTERACTIVE or use runtest -i to get this. Ouch, my ears. OTOH, the interactive winmm/wave tests sound fine. More precisely, all primary buffers of the form Nx24x1|2 or Nx32x1|2 produce various forms of hissing or plain noise. ../../../tools/runtest -i -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so dsound8.c dsound8.c:624: Testing a primary buffer at 96000x32x2 with a secondary buffer at 11025x16x2 ds3d8.c:332: Playing 1 second 440Hz tone at 11025x16x2 Assertion failed: (ptr1 < buflen), function DSOUND_BufPtrDiff, file mixer.c, line 305. wine: Assertion failed at address 0x0007:0x91c09f95 (thread 0009), starting debugger... Abort trap The wave tests report that 32bit width is unsupported. They also contain comment that 24bit width is not tested because ALSA has trouble with it. Yet dsound tests it? First I suspected this to be another instance of the broken DSOUND_PrimarySetFormat known from bug #20056 or bug #19124. OTOH, what happens here is different: WaveOpen fails initially, then the MAPPER+ACM kicks in and accepts to convert 24 or 32bit PCM to 16 => WaveOpen succeeds. On Linux, the sound is far from correct too, but there's no crash. With 24 or 32 bit tests outcomment in dsound8.c the only failure is: dsound8.c:624: Testing a primary buffer at 8000x16x2 with a secondary buffer at 11025x16x2 ds3d8.c:332: Playing 1 second 440Hz tone at 11025x16x2 ds3d8.c:517: Test failed: The sound played for 875 ms instead of 1000 ms (and 8kHz indeed sounds strange, while the other frequencies are much better). -- 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.

1 11

[Bug 27466] New: Broken listview
by wine-bugs＠winehq.org 15 Mar '13

15 Mar '13

http://bugs.winehq.org/show_bug.cgi?id=27466 Summary: Broken listview Product: Wine Version: 1.3.22 Platform: x86 URL: http://netikka.net/dev/Demo.exe OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: comctl32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: ocean04(a)suomi24.fi Example: http://netikka.net/dev/Demo.exe Click "Add rows" and scroll. Terminal is filled: err:listview:LISTVIEW_WindowProc unknown msg 1044 wp=00000000 lp=0032fb80 winetricks comclt32 -> its not broken anymore, but not all features work, like background, column higlight.. -- 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.

1 13

[Bug 11342] New: NFS3 demo version does not uninstall
by wine-bugs＠winehq.org 15 Mar '13

15 Mar '13

http://bugs.winehq.org/show_bug.cgi?id=11342 Summary: NFS3 demo version does not uninstall Product: Wine Version: 0.9.53. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: neptunia(a)mail.ru NFS3 demo version reports error when trying to uninstall. Possibly related to bug http://bugs.winehq.org/show_bug.cgi?id=11266. Download NFS3 demo version: http://www.gamershell.com/download_4364.shtml -- 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.

1 11

[Bug 27320] New: sims3 crashes after a while in wined3d
by wine-bugs＠winehq.org 15 Mar '13

15 Mar '13

http://bugs.winehq.org/show_bug.cgi?id=27320 Summary: sims3 crashes after a while in wined3d Product: Wine Version: 1.3.19 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com sims3 is unstable on my son's computer under ubuntu 10.10 and 11.04, and crashes after a few minutes of use. wine --version says wine-1.3.19-248-g6a3255b glxinfo says OpenGL renderer string: GeForce GT 220/PCI/SSE2 OpenGL version string: 3.3.0 NVIDIA 270.41.06 c:/users/dank/My Documents/Electronic Arts/The Sims 3/xcpt pantry 11-05-28 07.00.36.txt says type: ACCESS_VIOLATION reading address 0xfeeeff06 address: 0x68211d3f "C:\windows\system32\wined3d.dll":0x0001:0x00040d3f -- 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.

1 5

[Bug 28723] New: Sound stutter in Rage when emulated windows version is set to "Windows 7" (XAudio2 -> mmdevapi sound out path)
by wine-bugs＠winehq.org 15 Mar '13

15 Mar '13

http://bugs.winehq.org/show_bug.cgi?id=28723 Bug #: 28723 Summary: Sound stutter in Rage when emulated windows version is set to "Windows 7" (XAudio2 -> mmdevapi sound out path) Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winealsa.drv AssignedTo: wine-bugs(a)winehq.org ReportedBy: mooroon2(a)mail.ru CC: aeikum(a)codeweavers.com Classification: Unclassified Regression SHA1: b0652dd8bdb144645be4a6bf77cbb68a8ade49d9 This bug is twin-brother of fixed bug #28679. That one was when the app were using dsound API, this one seems to be when app uses mmdevapi directly. Same "first bad commit", reverting it fixes sound stutter in RAGE. I don't know any other Windows app I've got installed on my workstation which uses mmdevapi either directly or through XAudio2 (except for Starcraft II which seems to be unaffected by either this bug and bug #28679). Andrew, do you need usual sound-related debug logs for tracking this down? I can capture them from RAGE but I'm afraid they would be a bit polluted by unrelated messages from Steam client. -- 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.

1 158

[Bug 27855] New: entry field in Quicken98-2002 follows keys rather than filling out field
by wine-bugs＠winehq.org 15 Mar '13

15 Mar '13

http://bugs.winehq.org/show_bug.cgi?id=27855 Summary: entry field in Quicken98-2002 follows keys rather than filling out field Product: Wine Version: 1.3.24 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: jamesl(a)bestweb.net Created an attachment (id=35625) --> (http://bugs.winehq.org/attachment.cgi?id=35625) Quicken98 sample data (applies to Quicken98, Quicken 2000 and Quicken 2002. Have not tested against Quicken99 or 2001) In the window for writing checks, at the "payee" field, the normal behavior under Windows is that the field will try to find a match according to what you are typing. For example, if you were entering a check for "Sears Home Stuff", you would type the letters s, e, a, r, s, and the field would fill out the entry until it found the matching memorized transaction, which you could then select and continue on filling out the rest of the fields. Under Wine, in the same field if you type those letters, instead of filling out the field, it will show the first memorized transaction that matches that letter. Thus "S" would show "Saa...", "E" would show "Esso...", "A" would show "Amiga...", and so forth. Entering new data (any payee not memorized) can be difficult as well. It is possible to enter text by forcing the field to show it's dropdown list, but it's not what the user expects (in particular my older brother who discovered this bug <g>). Sample data files for the versions tested are attached. This bug occurs as late as Wine 1.3.24, and at least as far back as CrossoverOffice 9.1 (and whatever version of Wine that was based 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.

1 11

[Bug 28039] New: IAudioClock_GetPosition must ignore underruns (MacOS)
by wine-bugs＠winehq.org 15 Mar '13

15 Mar '13

http://bugs.winehq.org/show_bug.cgi?id=28039 Summary: IAudioClock_GetPosition must ignore underruns (MacOS) Product: Wine Version: 1.3.25 Platform: x86 OS/Version: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: mmdevapi AssignedTo: wine-bugs(a)winehq.org ReportedBy: hoehle(a)users.sourceforge.net GetPosition is critical because the new "winmm on mmdevapi" layer relies on it for its buffer management. Currently, neither winealsa nor winecoreaudio entirely fulfill GetPosition's contract. GetPosition yields "the stream position of the sample that is currently playing through the speakers". My tests show that it ignores underruns and is therefore not identical to a clock. One can derive at least 2 tests from that: 1. GetPosition <= elapsed time * samples/sec (cannot hear the future). 2. GetPosition <= sum of samples fed to the device. 3. GetPosition == sum of samples once all have been played. 4. Getposition is monotically increasing (except when Reset). Actually GetPosition does not yield samples, replace the above with GetPosition / GetFrequency * samples per sec to be correct. My tests attached to bug #27937 show that: - winecoreaudio fails test 3 (then 2). - winealsa with dmix fails test 1 during the first seconds of play. - winealsa with pulse fails test 1 much worse. See bug #27937 comment #1 and 2 for log snippets. On MacOS, GetPosition appears to continue to grow in the presence of underruns, violating 2 and 3. Hence the name of the present issue. Note that underruns are unknown to WINMM. A perfectly legal use is: waveOutOpen() waveOutPrepare(hugeboomheader) waveoutPrepare(clickheader) waveoutPrepare(ouchheader) waveoutPrepare(beepheader) then write the headers as the conditions arise (arguably dsound's mixing would be more adequate). Guess what happens when GetPosition grows playing nothing between 2 beeps? -- 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.

1 15

[Bug 13194] New: Gordian Knot unable to open codec settings dialog
by wine-bugs＠winehq.org 15 Mar '13

15 Mar '13

http://bugs.winehq.org/show_bug.cgi?id=13194 Summary: Gordian Knot unable to open codec settings dialog Product: Wine Version: 1.0-rc1 Platform: PC-x86-64 URL: http://sourceforge.net/projects/gordianknot OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvfw32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: emwine(a)earthlink.net Created an attachment (id=13019) --> (http://bugs.winehq.org/attachment.cgi?id=13019) testcase source and exe Install Codec Pack (for XviD), and rippack for GK. Run, go to options tab, click "First Pass" under XviD default codec settings. Nothing. Same with other codecs and "Codec settings" when trying a compressibility test. GK is open source, but in pascal. So I created a small testcase in VC++ 6.0 using the same technique. Testcase relies on XviD as opposed to other codecs. I'm not 100% sure that XviD (and other codecs) are properly registered so that the technique ought to work. But I think the problem is not codec registration. Also, I guessed at the component. -- 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.

1 13

[Bug 16975] New: [StrongDC++] switching between tabs show background windows
by wine-bugs＠winehq.org 15 Mar '13

15 Mar '13

http://bugs.winehq.org/show_bug.cgi?id=16975 Summary: [StrongDC++] switching between tabs show background windows Product: Wine Version: 1.1.12 Platform: PC URL: http://strongdc.sourceforge.net/download.php?lang=eng OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: bazara.net(a)inbox.ru If you open several tabs (windows) inside strongdc like hubs and click on a tab to switch to another hub you should see how all other opened background windows redraws until it show the one you clicked. If you have many opened hubs like 30 it will take several seconds to do that. -- 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.

1 5

[Bug 30071] New: Need a CreateTimerQueueTimer that is stable over time
by wine-bugs＠winehq.org 15 Mar '13

15 Mar '13

http://bugs.winehq.org/show_bug.cgi?id=30071 Bug #: 30071 Summary: Need a CreateTimerQueueTimer that is stable over time Product: Wine Version: 1.3.25 Platform: x86 OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: ntdll AssignedTo: wine-bugs(a)winehq.org ReportedBy: hoehle(a)users.sourceforge.net Classification: Unclassified Andrew Eikum's quick test in http://www.winehq.org/pipermail/wine-devel/2012-February/094457.html suggests that CreateTimerQueueTimer stabilizes itself over time on *average*. For instance, when asked for a 12ms period, it will trigger 5 times within 60ms even though it is unable to trigger every 12ms. The deltas are: 20, 10, 10, 10, 10, 20, 10, 10, 10, 10, ... This is an essential property that it would share with winmm timers. Both winealsa and wineoss today crucially depend on this property. The XAudio2 algorithm described in bug #28723 either writes one or zero period worth of data per callback. Hence it requires callbacks to agree with frame consumption by the audio device. If too late, XAudio2 will not catch up by writing 2 periods. What currently happens is irregular crackling due to occasional underruns because callbacks are further and further delayed and the audio buffers slowly empties. Compare timestamps from apps using winmm with mmdevapi: winmm mmdevapi x.304 x.304 x.315 x.315 x.324 x.326 x.334 x.336 x.346 x.348 x.354 x.359 winmm corrects itself and manages to trigger all 10ms events on the same millisecond as the initial one: x.xx4. CTQT accumulates delays because as its core, queue_timer_expire uses: [t->expire =] queue_current_time() + t->period; I've separated this issue from bug #28723 because the root cause is not an audio component and because several other bugs mention CreateTimerQueue, e.g. bug #29585. -- 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.

1 11