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

Re: wininet: Map socket errors to ERROR_INTERNET_CANNOT_CONNECT in create_netconn_socket.

by Hans Leidekker

On Wed, 2012-12-19 at 12:25 +0100, Marvin wrote: > 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=23542 > > Your paranoid android. > > > === W7PRO (32 bit http) === > http.c:3337: Test failed: HttpSendRequest failed: 12002 This is a timeout that occurs before the added test is run.

Dec. 19, 2012

Re: wininet: Map socket errors to ERROR_INTERNET_CANNOT_CONNECT in create_netconn_socket.

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=23542 Your paranoid android. === W7PRO (32 bit http) === http.c:3337: Test failed: HttpSendRequest failed: 12002

Dec. 19, 2012

Re: dsound: change mix rate of primary buffer

by Andrew Eikum

On Tue, Dec 18, 2012 at 08:08:03PM +0100, sebastien chev wrote: > Thank you for the tips. I will look at these. > I guess you're probably also thinking about the mix buffer in dsound itself. That does always mix to float, and there isn't a way to change it right now. What are you planning to use this for? We could support different mix buffer formats, but I'm not sure this use case is worth the effort. Andrew

Dec. 18, 2012

Clang static analyzer results / wine-1.5.19-186-g1cd0c4a

by Austin English

Now that http://source.winehq.org/git/wine.git/commitdiff/4adfb787f4e8c36a37ce1d53a7… is in (and clang has improved), several wine/clang bugs are fixed. For those curious, there is one remaining test failure on my machine, with clang instead of gcc: http://bugs.winehq.org/show_bug.cgi?id=25828 The static analyzer results were made with: llvm: git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk(a)170295 91177308-0d34-0410-b5e6-96231b3b80d8 clang: git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk(a)170294 91177308-0d34-0410-b5e6-96231b3b80d8 wine: wine-1.5.19-186-g1cd0c4a ./configure --disable-tests was used to reduce noise austin(a)debian-home:~$ du -h wine-1.5.19-186-g1cd0c4a.tar.bz2 39M wine-1.5.19-186-g1cd0c4a.tar.bz2 austin(a)debian-home:~$ sha1sum wine-1.5.19-186-g1cd0c4a.tar.bz2 bf86469ab3929faf996b76d4a8e533edcf24fd29 wine-1.5.19-186-g1cd0c4a.tar.bz2 Available at http://www.mediafire.com/?0gioifbgw363az3 -- -Austin

Dec. 18, 2012

winealsa: Separate read and write pointers.

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

Andrew Eikum wrote: >This [lock-less] seems to be the main goal of the patch. It'll not be bad to fix the capture bug independently. >and maybe we can get that into Wine after the next release? That requires agreement on the lock-less protocol. Basis: atomic 32bit updates. Do we want distinguished alignment declarations for e.g. This->held_frames? Write: InterlockedExchange/Increment/etc. is clear Read: Open for discussion Basically, all I need is a snapshot of a 32bit entity, i.e. an atomic read. The code doesn't bother whether that value is stale or not. It works in either case. All that is required is that it's updated some time eventually (i.e. not running off local cache for hours). Back in the old days, people used foo = (volatile X) bar; or even volatile X bar; ... foo=bar; Such code has been present e.g. in mciseq for the last 10 years. Currently, this has my preference for Intel: foo = bar; // e.g. held = This->held_frames; __asm__ __volatile__("":::"memory"); /* compiler barrier is enough for x86 */ I wouldn't be opposed to held = (volatile DWORD) This->held_frames; Purists spit at volatile for threading, but that's what has been used for decades and continues to be used (just google some random threading app...) I've also suggested InterlockedExchange(&held, This->held_frames) but that's just wasting a read of the obsolete value of held. So why use that form? Do we need to care for anything else than Intel? One may envision other approaches, e.g. a second critical section for the callback and Start/Stop only. But This->held_frames is updated within IAC_Get/ReleaseBuffer, so that doesn't solve the issue. POSIX purists would say that a protocol is needed between the two communicating threads (the Get/Release one and the cb, not the Start/Stop thread). But I don't care about POSIX requirements imposed by weird 8/16/24/32/40/64 bit HW and strange non-UNIX systems when the target is Wine-Is-Not-an-Emulator. Regards, Jörg Höhle

Dec. 18, 2012

Re: winealsa: Separate read and write pointers.

by Andrew Eikum

On Mon, Dec 17, 2012 at 05:01:29PM +0100, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Furthermore, this patch eases integration of my lock-less code, which > I'll not release for now, by cleanly separating read and write > pointers during playback and capture. No more adding of two volatile > entities moving in opposite directions! > This seems to be the main goal of the patch. I tested it against my usual set of applications both with and without PulseAudio. This patch seems fine to me. I'll take a look at your lockless patch on bug 29531, and maybe we can get that into Wine after the next release? Andrew

Dec. 18, 2012

Re: dsound: change mix rate of primary buffer

by Andrew Eikum

On Sun, Dec 16, 2012 at 11:56:46AM +0100, sebastien chev wrote: > It seems that no matter what the Windows side program choose for > DirectSoundCreate, the DSound subsystem initialize itself with the higher > spec sound available (for example 48Khz Float32, or 48kHz Int16 if no > Float32 available). > Maarten very recently updated dsound's behavior. It will either choose the default format for the backend or the nearest supported format to the format the application requests. See DSOUND_WaveFormat in <dsound/primary.c>. > While not a big deal on current linux PC, using this on ARM device kill > performance. > > A DirectSound subsystem for ARM, with Integer only for the mixbuffer (as > most ARM still use softfloat) and 22kHz should be less taxing for > performances. > It seems like the best solution is for the backend to prefer a format that the CPU supports efficiently. This requires some more intelligence in AudioClient_GetMixFormat in <winealsa.drv/mmdevdrv.c>, which currently probes for capabilities and chooses the best available format. Andrew

Dec. 18, 2012

Re: mmdevapi: Prevent race condition upon Start.

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

>>Since This->started was not set yet[...] >This doesn't make sense, there's a critical section. You are right, this one patch is only needed for my lock-less code, which I'll not submit for now. Good catch. (The minimal dueTime would benefit current code nevertheless, since critical section contention still requires the magnificient Linux scheduler to perform two more context switches until everything is ready. I've yet to write down the summary of my lock-contention tests. The result is not pretty, and my lock-less code significantly reduced underruns in mmdevapi/render/test_worst_case (aka. XA2 test).) Regards, Jörg Höhle

Dec. 18, 2012

Re: mmdevapi: Prevent race condition upon Start.

by Alexandre Julliard

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > What happened every so often, even on a single-core machine(!), is > that CreateTimerQueue(dueTime=0=immediate) would see the timer thread > created and the callback invoked before the function returns. Since > This->started was not set yet, our callback would return immediately, > in effect causing sound to start only one 10ms period later. > That's obviously was not intended by the author. > So let's set This->started before CTQ. This doesn't make sense, there's a critical section. -- Alexandre Julliard julliard(a)winehq.org

Dec. 18, 2012

Re: oleaut32: Dont output an error when the typelib cannot be found

by Alexandre Julliard

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > diff --git a/dlls/oleaut32/typelib.c b/dlls/oleaut32/typelib.c > index fa9b050..04914e0 100644 > --- a/dlls/oleaut32/typelib.c > +++ b/dlls/oleaut32/typelib.c > @@ -2544,9 +2544,11 @@ static HRESULT TLB_PEFile_Open(LPCWSTR path, INT index, LPVOID *ppBase, DWORD *p > return S_OK; > } > } > - > - hr = E_FAIL; > } > + > + TRACE("No TYPELIB resource found\n"); > + hr = E_FAIL; > + SetLastError(0); Setting last error to 0 is almost always wrong. In this case it's most likely just a side effect of CreateFile, and shouldn't need to be done explicitly. -- Alexandre Julliard julliard(a)winehq.org

Dec. 18, 2012