January 2012 - Wine-Devel - list.winehq.org

Re: [PATCH 2/2] winmm: Restore useful MMSYSERR_* codes at open time.

by Andrew Eikum

On Fri, Jan 27, 2012 at 02:02:22PM +0100, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > + case S_FALSE: /* as in IsFormatSupported */ > + case AUDCLNT_E_UNSUPPORTED_FORMAT: > + return WAVERR_BADFORMAT; I think I'd rather special-case how we handle IsFormatSupported, rather than put S_FALSE->BADFORMAT into the generic conversion. Andrew

Jan. 27, 2012

Re: vbscript: Get rid of unused SET_CALLED macro

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=16686 Your paranoid android. === WNT4WSSP6 (32 bit createobj) === createobj.c:731: Test failed: CoCreateInstance failed: 80040154 createobj: unhandled exception c0000005 at 00402A21

Jan. 27, 2012

Re: mmdevapi/tests: Perform renderer padding & position tests.

by Alexandre Julliard

Joerg-Cyril.Hoehle(a)t-systems.com writes: > Could you please investigate this? > The crash happens in test_session, before the one change to this > function by my patch. That would be easier to do if you sent smaller patches... -- Alexandre Julliard julliard(a)winehq.org

Jan. 27, 2012

mmdevapi/tests: Perform renderer padding & position tests.

by Joerg-Cyril.Hoehle＠t-systems.com

Alexandre, You wrote: >It doesn't work here: Backtrace: =>0 get_audio_session+0xbd() in winealsa 1 AudioClient_Initialize+0x5ae(iface=0x30c80, mode=AUDCLNT_SHAREMODE_SHARED, flags=0, duration=<is not available>, period=0x186a0, fmt=0x30f00, sessionguid=0x22fa00) [dlls/winealsa.drv/mmdevdrv.c:1075] in winealsa 2 test_session+0x114() [dlls/mmdevapi/tests/render.c:1298] in mmdevapi_test Could you please investigate this? The crash happens in test_session, before the one change to this function by my patch. The tests have been running thousands of iterations on my dual core MacOS (with my wip lock-free patches) and a single core Linux ALSA/dmix box. Several people have run the tests on native, including 64bit MS-Windows. I can't rule out that one of my latest additions may have introduced a bug, but so far I'd rather believe that my renderer tests have uncovered a bug in mmdevapi that shows up in your environment only. Why? On my side, I think I'll add ok(ref=0) checks around every IAC_Release. Thank you, Jörg Höhle

Jan. 27, 2012

Re: mmdevapi/tests: Perform renderer padding & position tests.

by Alexandre Julliard

Joerg-Cyril.Hoehle(a)t-systems.com writes: > Hi, > > this again fixes a few flaky failures on testbot but has potential > to introduce more flaky failures, esp. with PulseAudio. It doesn't work here: ../../../../wine/tools/runtest -q -P wine -M mmdevapi.dll -T ../../.. -p mmdevapi_test.exe.so ../../../../wine/dlls/mmdevapi/tests/render.c && touch render.ok render.c:1081: Tests skipped: Rerun with WINETEST_DEBUG=2 for GetPosition tests. render.c:1081: Tests skipped: Rerun with WINETEST_DEBUG=2 for GetPosition tests. wine: Unhandled page fault on read access to 0xffffffffffffffb8 at address 0x2adef8d7577d (thread 003f), starting debugger... Unhandled exception: page fault on read access to 0xffffffffffffffb8 in 64-bit code (0x00002adef8d7577d). Register dump: rip:00002adef8d7577d rsp:000000000022f830 rbp:000000000022fa00 eflags:00010283 ( R- -- I S - - -C) rax:0000000000000000 rbx:0000000000030af0 rcx:000000000022fa00 rdx:0000000000000000 rsi:00002adef8b53cb0 rdi:000000000022fa00 r8:0000000000000020 r9:000000000022f700 r10:0000000000000010 r11:000000000022f730 r12:0000000000000002 r13:ffffffffffffff98 r14:00002adef8f870f0 r15:0000000000030d90 Stack dump: 0x000000000022f830: 0000000000030f28 0000000000030c80 0x000000000022f840: 000000008007000e 0000000000000000 0x000000000022f850: 000000000022fa00 0000000000000000 0x000000000022f860: 0000000000000000 00002adef8d78e4f 0x000000000022f870: 0000000000000000 00002adef3fdcce1 0x000000000022f880: 000000000022fa48 0000000000030d68 0x000000000022f890: 0000000000000000 00002adef8d77f2f 0x000000000022f8a0: 0000000000031080 00002ade0000000e 0x000000000022f8b0: 000000000022f8e8 0000000000030d68 0x000000000022f8c0: 0000bb800022fa00 0000000400005355 0x000000000022f8d0: 5b5b5b5b5b5b5b5b 5b5b5b5b5b5b5b5b 0x000000000022f8e0: 2020202020202020 2020202020202020 Backtrace: =>0 0x00002adef8d7577d get_audio_session+0xbd() in winealsa (0x000000000022fa00) 1 0x00002adef8d78e4f AudioClient_Initialize+0x5ae(iface=0x30c80, mode=AUDCLNT_SHAREMODE_SHARED, flags=0, duration=<is not available>, period=0x186a0, fmt=0x30f00, sessionguid=0x22fa00) [/home/julliard/wine/build/obj-elf64/dlls/winealsa.drv/../../../wine/dlls/winealsa.drv/mmdevdrv.c:1075] in winealsa (0x000000008007000e) 2 0x00002adef3fd6fb5 test_session+0x114() [/home/julliard/wine/build/obj-elf64/dlls/mmdevapi/tests/../../../../wine/dlls/mmdevapi/tests/render.c:1298] in mmdevapi_test (0x0000000000000000) 3 0x00002adef3fda2d3 func_render+0x292() [/home/julliard/wine/build/obj-elf64/dlls/mmdevapi/tests/../../../../wine/dlls/mmdevapi/tests/render.c:2150] in mmdevapi_test (0x000000000022fb38) 4 0x00002adef3fcc429 main+0x308(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/build/obj-elf64/dlls/mmdevapi/tests/../../../../wine/include/wine/test.h:556] in mmdevapi_test (0x000000000001079c) 5 0x00002adef3fdd8c2 __wine_spec_exe_entry+0xa1(peb=<is not available>) [/home/julliard/wine/build/obj-elf64/dlls/winecrt0/../../../wine/dlls/winecrt0/exe_entry.c:36] in mmdevapi_test (0x00002adef2285a30) 6 0x00002adef3278404 start_process+0xb3(peb=0x7fffffbef000) [/home/julliard/wine/build/obj-elf64/dlls/kernel32/../../../wine/dlls/kernel32/process.c:1053] in kernel32 (0x00002adef3fdd820) 7 0x00002adef2ae328b call_thread_func+0x6a(entry=0x2adef3278350, arg=0x7fffffbef000, frame=0x0(nil)) [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/signal_x86_64.c:3189] in ntdll (0x00007fff3177aa50) 8 0x00002adef2adcbb6 call_thread_entry_point+0x29() in ntdll (0x00007fff3177aa50) 9 0x00002adef2aaf1d6 start_process+0x15(kernel_start=<is not available>) [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/loader.c:2612] in ntdll (0x00007fff3177aa50) 10 0x00002adef1f5f3a3 wine_call_on_stack+0x12() in libwine.so.1 (0x00007fff3177aa50) 11 0x00002adef1f5f3f9 wine_switch_to_stack+0x8(func=<is not available>, arg=<is not available>, stack=<is not available>) [/home/julliard/wine/build/obj-elf64/libs/wine/../../../wine/libs/wine/port.c:59] in libwine.so.1 (0x00007fffffbef000) 12 0x00002adef2ab4f10 LdrInitializeThunk+0x45f(kernel_start=0x2adef3278350, unknown2=<is not available>, unknown3=<is not available>, unknown4=<is not available>) [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/loader.c:2668] in ntdll (0x00007fffffbef000) 13 0x00002adef327e885 __wine_kernel_init+0x8f4() [/home/julliard/wine/build/obj-elf64/dlls/kernel32/../../../wine/dlls/kernel32/process.c:1254] in kernel32 (0x00007fff3177bce0) 14 0x00002adef2ab5874 __wine_process_init+0x273() [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/loader.c:2877] in ntdll (0x0000000000000400) 15 0x00002adef1f5d325 wine_init+0x294(argc=<is not available>, argv=0x7fff3177c4b8, error="", error_size=0x400) [/home/julliard/wine/build/obj-elf64/libs/wine/../../../wine/libs/wine/loader.c:831] in libwine.so.1 (0x0000000000000400) 16 0x000000007bf00d41 main+0x70(argc=0x3, argv=0x7fff3177c4b8) [/home/julliard/wine/build/obj-elf64/loader/../../wine/loader/main.c:230] in <wine-loader> (0x0000000000000003) 17 0x00002adef24ebead __libc_start_main+0xfc(main=<is not available>, argc=<is not available>, ubp_av=<is not available>, init=<is not available>, fini=<is not available>, rtld_fini=<is not available>, stack_end=0x7fff3177c4a8) [/home/aurel32/eglibc/eglibc-2.13/csu/libc-start.c:228] in libc.so.6 (0x0000000000000000) 18 0x000000007bf00e3d _start+0x28() in <wine-loader> (0x0000000000000000) 0x00002adef8d7577d get_audio_session+0xbd in winealsa: cmpq 0x0000000000000020(%r13),%rbx -- Alexandre Julliard julliard(a)winehq.org

Jan. 26, 2012

Re: winmm: Parse MCI colon notation as in T:MM:SS:F.

by Alexandre Julliard

Joerg-Cyril.Hoehle(a)t-systems.com writes: > + if (seen < 2) return FALSE; > + if (shift && (val >= 256 || (seen&1))) return FALSE; > + total |= val << shift; > + *data = (seen&1) ? -total : total; > + *ptr = ret; > + return TRUE; This is still fairly ugly. If you need two flags, declare two flag variables, instead of that sort of counter/flag mix. -- Alexandre Julliard julliard(a)winehq.org

Jan. 26, 2012

Re: [2/2] scrrun: Register Scripting interfaces

by Jacek Caban

On 01/25/12 15:03, Nikolay Sivov wrote: > On 1/25/2012 15:21, Jacek Caban wrote: >> On 01/25/12 11:59, Nikolay Sivov wrote: >>> On 1/25/2012 12:35, Alistair Leslie-Hughes wrote: >>>> Hi, >>>> >>>> >>>> Changelog: >>>> scrrun: Register Scripting interfaces >>> Some of this are already used in wshom.ocx, I'm not sure which one >>> should take precedence and implement that. Probably it changed in >>> recent Windows versions? >> Note that there is already an overlap with wscript.exe and wshom.ocx. We >> may consider moving common parts to a global header if needed, but I'm >> not sure we care much at this point. Also it looks like scrrun.dll it >> the dependency of others. It exports DoOpenPipeStream, which suggests >> that others should use it at least for streams implementation, but it's >> undocumented, so it problematic for us anyway. > That's what I meant, it should be implemented in one place, after that > you probably won't need > duplicated *.idls. Moving the implementation won't change the fact that they need to be in all typelibs, so it will still need to be in global file or duplicated. Jacek

Jan. 26, 2012

brainstorm: what are the audio stumbling blocks?

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, What are the areas that would have the most impact if fixed? You are invited to participate and share your thoughts. I believe we need to distinguish winmm/dsound/mmdevapi/OS. mmdevapi: A. lock-less timer callback design, bug #. But I don't think where we would get the most improvement from avoiding a few EnterCriticalSection. B. Stability of time base, bug #. Perhaps major. My render "worst case" test showed that CreateTimerQueue never invoked callbacks every 10ms as asked rather than 8 or 12ms. I don't know if that's the Linux jiffies we see here. C. too small ALSA buffer for the backend I've sketched a "hidden frames" design that would allow using a larger ALSA or OSS buffer, but that needs a reliable estimate of how much ALSA has buffered. Also, that's at odds with DSound and XAudio2 which want short latency and presumably don't send much data in advance. Every audio HW guy recommends using audio buffers as large as possible. Can't we just because of the f**ing 10ms period? D. timer frequency Is it really important to match native's 10ms period? The UNIX world is trying to decrease the number of interrupts in order to preserve battery life, but we go backwards and move from a model which dynamically computed the next wake-up based on the number of submitted frames to a tiny fixed period. Are we crazy? E. lead-in aka. "ALSA won't start", bug # F. lead-out aka. finish playing trailing frames not modulo period size, bug # G. other mmdevapi winmm: H. GetPosition is not (yet) == mmdevapi's GetPosition I. other winmm DSound: J. time base? It uses timeSetEvent. What if using mmdevapi's event? K. buffer size too small or not matching whatever needs? L. issues with GetCurrentPadding/GetPosition The "true position" may be too far away from the write pointer, e.g. PA's typical 2s latency. Deal with that, matching DSound's and the apps' expectations as well as Linux/BSD/OSX sound systems. M. DSound's underlying model is a ring buffer. This does not match mmdevapi's. Should we bypass mmdevapi because all it adds is latency? Reinvent HW acceleration? Provide a hidden API in mmdevapi? N. other DSound XAudio2: Modern apps will use that because mmdevapi is too low-level, presumably DSound usage will decrease. O. XAudio2 appears to use the "worst case small period size writes" known from the Rage bug # P. other Capture: Q. whatever capture issues UNIX host: R. thread priority -- no "Pro Audio" / Real-Time priority S. reliability of event/interrupt delivery over sustained intervals (hours, not minutes). T. Wine SetEvent & server round-trip times Other: U. FMOD & whatever, any particular constraints? V. other? Thanks for your contribution, Jörg Höhle

Jan. 26, 2012

fwd: winealsa: snd_card_get_name uses strdup (Valgrind).

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Andrew Eikum updated ALSA's documentation http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=226a34ac09e5d9c0… Now that free() is documented, the pending patch #82900 should be applied. Regards, Jörg Höhle

Jan. 26, 2012

Re: shell32: Use simple helper for case insensitive strstr()

by Nikolay Sivov

On 1/25/2012 13:36, Alexandre Julliard wrote: > Nikolay Sivov<nsivov(a)codeweavers.com> writes: > >> Fix for http://bugs.winehq.org/show_bug.cgi?id=28087 > You shouldn't need anything of the kind. If StrStrIW doesn't work right > it should be fixed (plus of course there's no reason to even use > strstr() here at all). When I debugged that I remember there's was a problem with CompareStringW() actually. StrStrIW() eventually uses it like: --- iRet = CompareStringW(GetThreadLocale(), NORM_IGNORECASE, lpszStr, iLen, lpszComp, iLen); --- so both strings are passed with the same length. CompareStringW() in turn uses winelib's wine_compare_string() that tries to actualize passed string length look backwards from string tail searching for first not null - helper real_length(). So it easily gets past string data if specified length is large enough. Some tests show that CompareStringW() survives in such case - it uses 'or' it seems, so it doesn't matter what happens first: a null terminator or consumed chars count. So yeah, this probably should be fixed, but requires winelib changes and a test that will crash without a fix, not in very reliable way depending on string length passed to it. About avoiding strstr() at all, does this one look ok - http://bugs.winehq.org/attachment.cgi?id=38556 ?

Jan. 26, 2012