September 2011 - Wine-devel

mmdevapi performance analysis
by Joerg-Cyril.Hoehle＠t-systems.com 28 Sep '11

28 Sep '11

Hi, While the 3D guys work on performance improvements, we audio guys kill it. Luckily gfx data is shuffled around in MB/s, audio only in hundred kB/s, so hopefully it doesn't weight that much. Let's have a look at how data wanders around with dsound, winmm and mmdevapi. waveOutWrite with mmdevapi: copy to mmdevapi ALSA/OSS buffer copy some in case of mmdevapi buffer wrap around write buffer to ALSA/OSS waveOutWrite old driver model: write header to ALSA/OSS waveOutWrite involving MSACM with mmdevapi: convert PCM to MSACM, writing to new buffer copy to mmdevapi ALSA/OSS buffer copy some in case of buffer wrap around write to ALSA/OSS Here, if msacm/waveform.c had the courage to delay conversion until GetBuffer time, some copying could be avoided as msacm would write directly into mmdevapi's buffer. Being overly protective ("I should convert before GetBuffer because afterwards I might not have enough time") ends up wasting CPU cycles, hence paradoxically increasing the probability of being late thus causing underruns. The cause for the impedance mismatch between winmm and mmdevapi is what I call "owner inversion". The app supplies winmm with a pointer to its data buffers. As mmdevapi does the same, some transfer is needed between both. Arguably, mmdevapi is not the best target for winmm in Wine... DSOUND_WaveQueue newest "reimplement rendering on mmdevapi" in 1.3.30: write to dsound secondary buffer mix secondary to primary buffer copy to mmdevapi buffer copy some more in case of mmdevapi buffer wrap around write buffer to ALSA/OSS It looks like the new code misses the opportunity to equate device buffer with primary buffer. Instead we've got a cascade of buffers. Why is dsound's primary (mixing target) not mmdevapi's buffer? What's the goal? Ideally, 1. ALSA's mmdevdrv Get/ReleaseBuffer use snd_pcm_mmap_begin/commit, avoiding copying from mmdevapi to ALSA; 2. mmdevapi's buffer becomes DSound's primary, avoiding copying from dsound to mmdevapi. This applies even to CoreAudio where there's not really an mmdevapi buffer. The result: DSound's mixer talks straight with the HW. This should be no surprise. mmdevapi's shared mode mixer probably has roots in dsound's. BTW, what prevents equating dsound's secondary buffers with mmdevapi's shared mode streams and let the underlying device perform the mixing? Regards, Jörg Höhle

1 0

Update on testbot
by Maarten Lankhorst 28 Sep '11

28 Sep '11

Hi all, I moved the windows 7 x64 vm with sp1 applied to the base pool now. This means that all submitted patches will be run on that vm as well. The original win7 vm is still available under its own name. Since all tests pass on that according to winehq tests I'm keeping it in the base pool. I hope to see all tests on the new vm fixed as well. They mostly appear to be related to the ie9 update, but msctf:inputprocessor and msi:install fail as well. ~Maarten

2 1

Re: mscoree: Add ICorDebug interface support (try 3)
by Vincent Povirk 28 Sep '11

28 Sep '11

It's OK to call CLRMetaHost methods directly with a NULL ICLRMetaHost instance. It's a singleton, and none of the methods use the interface. You might want to check whether you get a new ICorDebug interface every time you request one. I suspect you do. On Wed, Sep 28, 2011 at 1:21 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi, > Changed to use ICLRRuntimeInfo::GetInterface, suggest by Vincent. > Moved the #undef to the header. > > > Changelog: > mscoree: Add ICorDebug interface support > > > Best Regards > Alistair Leslie-Hughes > > > > > >

1 0

Re: mscoree: Add ICorDebug interface support (try 3)
by Marvin 28 Sep '11

28 Sep '11

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=14599 Your paranoid android. === W2K3R2SESP2 (32 bit debugging) === debugging.c:82: Test failed: CreateDebuggingInterfaceFromVersion returned 80070057

1 0

re: dsound: Place storage class before type qualifier
by Dan Kegel 27 Sep '11

27 Sep '11

Hi Andrew, doesn't seem to apply here: $ patch -p1 < 79377.patch patching file dlls/dsound/dsound_main.c Hunk #1 FAILED at 319. 1 out of 1 hunk FAILED -- saving rejects to file dlls/dsound/dsound_main.c.rej ---------- Forwarded message ---------- From: <buildbot(a)kegel.com> Date: Tue, Sep 27, 2011 at 2:50 PM Subject: Re: 79377: dsound: Place storage class before type qualifier To: dank(a)kegel.com, wine-tests-results(a)winehq.org This is an experimental automated build and test service. Please feel free to ignore this email while we work the kinks out. For more info about this message, see http://wiki.winehq.org/BuildBot The Buildbot has detected a failed build on builder runtests-default while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/128 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) BUILD FAILED: failed git Errors: error: patch failed: dlls/dsound/dsound_main.c:319 error: dlls/dsound/dsound_main.c: patch does not apply

1 0

Re: [PATCH] kernel32: make it possible to create a backtrace from a RaiseException exception in gdb
by Alexandre Julliard 27 Sep '11

27 Sep '11

Bernhard Loos <bernhardloos(a)googlemail.com> writes: > @@ -60,6 +60,17 @@ static PTOP_LEVEL_EXCEPTION_FILTER top_filter; > typedef INT (WINAPI *MessageBoxA_funcptr)(HWND,LPCSTR,LPCSTR,UINT); > typedef INT (WINAPI *MessageBoxW_funcptr)(HWND,LPCWSTR,LPCWSTR,UINT); > > +#ifdef __i386__ > +/* without this, it's impossible to get a backtrace from the raised > + * exception in winedbg in gdb mode */ > +void RaiseException_helper(EXCEPTION_RECORD *r, void *f) DECLSPEC_HIDDEN; > +__ASM_GLOBAL_FUNC(RaiseException_helper, > + "mov 0x4(%esp),%eax\n\t" > + "push %eax\n\t" > + "mov 0xc(%esp),%eax\n\t" > + "call *%eax\n\t" > + "ret") > +#endif You shouldn't need anything like that. -- Alexandre Julliard julliard(a)winehq.org

2 3

re: winmm: waveOutReset returns all buffers.
by Dan Kegel 27 Sep '11

27 Sep '11

Fails to apply here. (Requires fuzz, which Alexandre says is verboten.) ---------- Forwarded message ---------- From: <buildbot(a)kegel.com> Date: Mon, Sep 26, 2011 at 2:35 AM Subject: Re: 79321: winmm: waveOutReset returns all buffers. To: dank(a)kegel.com, wine-tests-results(a)winehq.org This is an experimental automated build and test service. Please feel free to ignore this email while we work the kinks out. For more info about this message, see http://wiki.winehq.org/BuildBot The Buildbot has detected a failed build on builder runtests-default while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/63 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) BUILD FAILED: failed git Errors: error: patch failed: dlls/winmm/waveform.c:1653 error: dlls/winmm/waveform.c: patch does not apply

2 2

Re: [PATCH] ntdll/signal_i386.c: RtlCaptureContext locals + args are 12 bytes instead of 8 (return address + CONTEXT * arg + %eax local
by Alexandre Julliard 27 Sep '11

27 Sep '11

Bernhard Loos <bernhardloos(a)googlemail.com> writes: > @@ -1181,7 +1181,7 @@ __ASM_STDCALL_FUNC( RtlCaptureContext, 4, > __ASM_CFI(".cfi_adjust_cfa_offset 4\n\t") > "popl 0xc0(%eax)\n\t" /* context->EFlags */ > __ASM_CFI(".cfi_adjust_cfa_offset -4\n\t") > - "leal 8(%esp),%edx\n\t" > + "leal 0xc(%esp),%edx\n\t" > "movl %edx,0xc4(%eax)\n\t" /* context->Esp */ That's not really more correct, it's supposed to return the caller frame but there's no good way of doing that. What are you trying to fix? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: mscoree: Add ICorDebug interface support (try 2)
by Vincent Povirk 27 Sep '11

27 Sep '11

You really should implement the .NET 4 version of this first (MSDN helpfully points to ICLRRuntimeInfo::GetInterface, which is CLRRuntimeInfo_GetInterface in our code), then implement the legacy version based on that, so everything is in one place. On Tue, Sep 27, 2011 at 6:34 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi, > Add missing test file. > > Changelog: > mscoree: Add ICorDebug interface support > > > Best Regards > Alistair Leslie-Hughes > > > > >

1 0

Re: mscoree: Add ICorDebug interface support
by Vincent Povirk 27 Sep '11

27 Sep '11

Why aren't you using CLRRuntimeInfo_GetInterface for this?

1 0