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

Re: [PATCH 1/4] server: Add mechanism to store and retrieve information about a socket (try 2).
by Vitaliy Margolen Jan. 13, 2012

Jan. 13, 2012

On 01/13/2012 12:05 AM, Erich E. Hoover wrote: > Real Name: > Erich Hoover > > Changelog: > server: Add mechanism to store and retrieve information about a socket. > > + > +/* Get and set user-accessible socket variables */ > +(a)REQ(get_socket_variable) > + obj_handle_t handle; /* handle to the socket */ > + unsigned int varcode; /* variable to return */ > + unsigned int varsize; /* size of variable to return */ > +(a)REPLY > + char ok; /* operation status */ > + int value; /* returned value of variable */ > +(a)END > + > +(a)REQ(set_socket_variable) > + obj_handle_t handle; /* handle to the socket */ > + unsigned int varcode; /* variable to set */ > + unsigned int varsize; /* size of variable to set */ > + int value; /* value of variable to set */ > +(a)REPLY > + char ok; /* operation status */ > +(a)END You are not using "ok" parameters in either of the calls. You should use status returned by wine_server_call_() for things like that. Also size seems to be redundant here. If it's an int - store it as int on both sides. This also implies you should use an array instead of struct for a storage. And drop size checks. One more thing, keep in mind that time_t is not unsigned int. But long. Vitaliy.

1 0

Re: kernel32: Specify the access rights when creating a file object.
by Alexandre Julliard Jan. 13, 2012

Jan. 13, 2012

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > While investigating how to fix the file section access tests in kernel32 I've > found that some places in Wine deliberately create objects with access rights > set to 0, that leads to creation of potentially not accessible objects. Many of these are deliberate. You'll need test cases to show that you can require more permissions. -- Alexandre Julliard julliard(a)winehq.org

2 5

Re: [PATCH 1/4] server: Add mechanism to store and retrieve information about a socket (try 2).
by Alexandre Julliard Jan. 13, 2012

Jan. 13, 2012

"Erich E. Hoover" <ehoover(a)mines.edu> writes: > Real Name: > Erich Hoover > > Description: > This patch implements storing of internal information about a > socket. The intent for this approach is to add a dynamic mechanism to > permit the storage of various variables that are accessible in user > space, such as storing of the connect() time (part 2). That's ugly, you don't need an arbitrary opaque variable storage mechanism. Just store the connect time and return it as such. Besides, you don't even need to set it from the client side, the server is notified on connect. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: comctl32: Return correct background color
by Marvin Jan. 13, 2012

Jan. 13, 2012

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=16419 Your paranoid android. === WNT4WSSP6 (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0xffffffff === W2KPROSP4 (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0xffffffff === WXPPROSP3 (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0xffffffff === W2K3R2SESP2 (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0xffffffff === WVISTAADM (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0xffffffff === W2K8SE (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0xffffffff === W7PRO (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0xffffffff === W7PROX64 (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0xffffffff === TEST64_W7SP1 (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0xffffffff === W7PROX64 (64 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0xffffffff === TEST64_W7SP1 (64 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0xffffffff

1 0

Re: po: Update French translation
by Francois Gouget Jan. 12, 2012

Jan. 12, 2012

On Thu, 12 Jan 2012, Frédéric Delanoy wrote: [...] > #: appwiz.rc:64 > msgid "&Support Info" > -msgstr "Inf&ormations de support..." > +msgstr "Inf&ormations de support" I don't know why 'Information' was abbreviated in English. This should be checked and unabbreviated if it was abusive. But if it's because of a lack of space, for instance, then we should probably abbreviate it in French too (even if it means the spellchecker complains :-/). Besides that, thanks a lot for the patch. It looks like it's going to fix a lot of the issues reported on my wine-po site: http://fgouget.free.fr/wine-po/ Btw, if anyone feels like tackling some of them I'll gladly accept all the help I can get. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.

2 2

Vista/w2k8/w7 + ALSA users, please test mmdevapi capture
by Joerg-Cyril.Hoehle＠t-systems.com Jan. 12, 2012

Jan. 12, 2012

Hi, Thanks to all five users who sent me data. I've a new testbot job. Please download mmdevapi_test32|64.exe http://testbot.winehq.org/JobDetails.pl?Key=16386 you don't need a microphone, just a capture capable sound card, unlike testbot. there should be next to 0 failures in lines 200-410. Failures in 411-600 (function test_capture2) are not interesting. It would be good to repeat the test a few times to see whether there's a random failure. Also, please compare mmdevapi_test[64].exe capture with mmdevapi_test[64].exe capture > capture.log Redirecting to a file leads to vastly different results (in the render tests) because output to the MS-DOS shell is extremely slow and thus affects timing. On a 64bit machine, you may also compare the output of both executables. The behaviour is apparently not the same! On Unix with ALSA, you may try my latest patches from source.winehq.org/patches and see if it works for you. - Stop without snd_pcm_drop patch - Reset accounting patch - CaptureClient protocol patch I'm at 0 failures (ignoring test_capture2) and a few todo with dmix and 0-1 (random) with PulseAudio. Please post or send me the results -- not just the failures, the console output too including position/padding/flags. Thank you for testing, Jörg Höhle

3 2

Re: [PATCH 1/5] ddraw/tests: Add some clipper tests.
by Saulius Krasuckas Jan. 12, 2012

Jan. 12, 2012

* On Wed, 4 Jan 2012, Henri Verbeet wrote: > --- > dlls/ddraw/tests/ddraw1.c | 217 +++++++++++++++++++++++++++++++++++++++++++++ > dlls/ddraw/tests/ddraw2.c | 217 +++++++++++++++++++++++++++++++++++++++++++++ > dlls/ddraw/tests/ddraw4.c | 216 ++++++++++++++++++++++++++++++++++++++++++++ > dlls/ddraw/tests/ddraw7.c | 216 ++++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 866 insertions(+), 0 deletions(-) It's http://source.winehq.org/git/wine.git/commitdiff/3997457574a0e3f1c2fa095e23… These tests fail on real machines (running XP and w7) with nVidia cards (FX5200 and GF 310M): http://test.winehq.org/data/b00e7039c5fcaa613b9776a38fe60bb697146b42/index_… http://test.winehq.org/data/a86b765a50cdf76e66c8993977f892d825f52ec0/index_… On XP + FX5200 the first three tests (dd1, dd2, dd4) generates crash with failing hr = 0x8876021c. The other cases just fail by some color matches. Plus, tests fail on one WTB machine running XP with russian localisation + "VMware SVGA II" v11.6.0.35 in yet different way: http://test.winehq.org/data/b00e7039c5fcaa613b9776a38fe60bb697146b42/xp_wtb… Other virtual XP machines do OK with similar setup. My humble guess -- that's just one broken setup out of many virtual machines. Henri, would you be as kind as to fix the tests:)? S.

2 2

Re: [2/2] msvcrt: Forward strftime() to wcsftime(). Take 2.
by Alexandre Julliard Jan. 12, 2012

Jan. 12, 2012

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > + len = MultiByteToWideChar( CP_ACP, 0, format, -1, NULL, 0 ); > + if ((fmt = MSVCRT_malloc( len * sizeof(MSVCRT_wchar_t) ))) > + { > + MultiByteToWideChar( CP_ACP, 0, format, -1, fmt, len ); > + > + if ((len = MSVCRT_wcsftime( s, max, fmt, mstm ))) > + { > + len = WideCharToMultiByte( CP_ACP, 0, s, len, str, max, NULL, NULL ); > + if (len < max) str[len] = 0; > + } The overflow handling still looks suspicious. It probably needs some more test cases. -- Alexandre Julliard julliard(a)winehq.org

2 6

Re: mscoree: Implement DllGetClassObject (try 2)
by Vincent Povirk Jan. 12, 2012

Jan. 12, 2012

You're still using a single static class object, and I'm not convinced GetIDispatchForObject is a good idea. On Wed, Jan 11, 2012 at 5:02 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi, > Use RegGetValueW for the class. > > Changelog: > mscoree: Implement DllGetClassObject > > > Best Regards > Alistair Leslie-Hughes > > > >

1 0

[PATCH 5/8] dsound: Make capture behave like native in regards to COM aggregation.
by Joerg-Cyril.Hoehle＠t-systems.com Jan. 12, 2012

Jan. 12, 2012

Hi, Michael Stefaniuc wrote: >static HRESULT WINAPI IDirectSoundCaptureImpl_CreateCaptureBuffer + if (pUnk) { + WARN("invalid parameter: pUnk != NULL\n"); + /* *lplpDSCaptureBuffer = NULL; Not done by native dsound */ + return DSERR_NOAGGREGATION; + } What's your rationale for doing so? Bug compatibility with native is fine, however not setting NULL is problematic before you've reached 100% compatibility, have you? What I mean is that if there's a situation where Wine's CreateCaptureBuffer returns some DSERR such as NOTIMPL where native does not, then that's an unexpected situation for the app which it may not be well prepared to handle, as it is untestable on native. Now not zeroing output pointers may make it even harder for the app to remain in sane state. Then blame the app or Wine for a crash? If OTOH you know that the Wine module *always* returns the exact same values as native, then I've no objection in not zeroing output pointers when native does neither. Yet you'll have to consider that native may do so in the future, witness a growing number of MSDN documents covering later APIs that specifically mention zeroing pointers in case of failure. IIRC, AJ removed from my mmdevapi tests one snippet that showed that native's GetService does not zero an output pointer even though MSDN says so -- Wine zeroes. Yet perhaps I got confused, messed up with patches and submitted the one that did not contain that test so maybe AJ never had a chance to see it. I'll have to check that. Regards, Jörg Höhle

3 3

Re: jscript: Don't use break in funally block on pre-IE8 jscript
by Marvin Jan. 12, 2012

Jan. 12, 2012

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=16400 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

2 1

Interesting - performance issues in Natural Selection 2 dedicated server
by Scott Ritchie Jan. 12, 2012

Jan. 12, 2012

The game is still in beta development, but I just learned something odd - there are no Linux server binaries (yet), and a lot of admins are running the dedicated server using Wine. Wine works, but is actually performing fairly poorly here. I find this really interesting, as the dedicated server isn't graphical in any way. Would profiling here be worthy of pursuing? Are there known areas of bad performance other than graphics? Thanks, Scott Ritchie

2 1

Re: [PATCH] mshtml: Add interface for nsIWebBrowserChrome2 and 3
by Jacek Caban Jan. 12, 2012

Jan. 12, 2012

Hi Detlef, Why do you add them? nsiface.idl should contain only interfaces that we use. Otherwise it's just adding me more work on each Gecko merge. Jacek

1 0

d3dx9: Implement D3DXCreatePolygon
by David Adam Jan. 11, 2012

Jan. 11, 2012

Hello are there still problems with the patches: http://source.winehq.org/patches/data/82408 and http://source.winehq.org/patches/data/82409 ? Thanks in advance A+ David

1 0

MacOS recording audio - chunking 4096 frames
by Joerg-Cyril.Hoehle＠t-systems.com Jan. 11, 2012

Jan. 11, 2012

Hi, looking at mmdevapi/tests/capture logs, I found 2 issues 1. the 5 buffers initially sent are all returned with 0 bytes So I added a loop to return empty buffers to the audio input queue, such that GetBuffer returns data when GetCurrentPadding shows it. But why were these buffers returned at all? Why initially submit the buffers if they are always returned empty? 2. Using a ~500ms mmdevapi duration, Wine gave MacOS CoreAudio 5 buffers of ~4399 frames each. However, MacOS solely returned 4096 frames. Is anybody aware of such chunking? I'd like to know about such chunking, because IMHO the correct way to handle it would be to advertise mmdevapi's a matching default recording period -- obviously not 10ms. I believe the current mmdevapi code did not expect that behaviour and therefore does not manage to fill as much frames as GetBufferSize would allow into a buffer. I haven't checked smaller buffers. I'd like to avoid bombarding CoreAudio with 10ms buffer requests of 480 frames each just because native mmdevapi advertises a 10ms period. Thank you for your help, Jörg Höhle

2 1

Vista/w2k8/w7 users, please test mmdevapi capture
by Joerg-Cyril.Hoehle＠t-systems.com Jan. 11, 2012

Jan. 11, 2012

Hi, you don't need a microphone, just a capture capable sound card, unlike testbot. Please download mmdevapi_test32|64.exe from testbot: http://testbot.winehq.org/JobDetails.pl?Key=16376 run: mmdevapi_test capture and post or send me the results -- not just the failures, the console output too including position/padding/flags. Don't be afraid of some test failures in lines 300-499. I'm still investigating underrun and start/stop/reset behaviour. Thank you for testing, Jörg Höhle

3 2

Re: mscoree: Implement DllGetClassObject
by Vincent Povirk Jan. 11, 2012

Jan. 11, 2012

You can't just use a static class factory for all the classes. There's no need for GetIDispatchForObject when we already have GetIUnknownForObject (and all you use is QueryInterface). + res = RegGetValueA( key, NULL, "Class", RRF_RT_REG_SZ, NULL, classname, &dwBufLen); We should probably use a W function here and convert to utf8, rather than assume that's the default encoding.

2 2

Re: [PATCH 3/5] d3d9: Don't expose wined3d internal flags to the application.
by Alexandre Julliard Jan. 11, 2012

Jan. 11, 2012

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > --- > dlls/d3d9/buffer.c | 4 ++-- > dlls/d3d9/cubetexture.c | 2 +- > dlls/d3d9/surface.c | 2 +- > dlls/d3d9/texture.c | 2 +- > dlls/d3d9/volume.c | 2 +- > dlls/d3d9/volumetexture.c | 2 +- > 6 files changed, 7 insertions(+), 7 deletions(-) This is causing test failures: ../../../tools/runtest -q -P wine -M d3dx9_36.dll -T ../../.. -p d3dx9_36_test.exe.so mesh.c && touch mesh.ok mesh.c:331: Test succeeded inside todo block: Test createmesh1, result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test createmesh2, result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test createmeshfvf, result 0, expected 0 mesh.c:2497: Tests skipped: D3DXCreateBox failed mesh.c:331: Test succeeded inside todo block: Test sphere (0, 2, 2), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test sphere (1, 2, 2), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test sphere (1, 3, 2), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test sphere (1, 4, 4), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test sphere (1, 3, 4), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test sphere (5, 6, 7), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test sphere (10, 11, 12), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test cylinder (0, 0, 0, 2, 1), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test cylinder (1, 1, 1, 2, 1), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test cylinder (1, 1, 2, 3, 4), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test cylinder (3, 2, 4, 3, 4), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test cylinder (2, 3, 4, 3, 4), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test cylinder (3, 4, 5, 11, 20), result 0, expected 0 mesh.c:3679: Test succeeded inside todo block: Test text ('wine', 340282346638528859811704183484516925440.000000, 0.400000), result 0, expected 0 mesh.c:3679: Test succeeded inside todo block: Test text ('wine', 0.001000, 0.000000), result 0, expected 0 mesh.c:3679: Test succeeded inside todo block: Test text ('wine', 0.001000, 0.000000), result 0, expected 0 mesh.c:3679: Test succeeded inside todo block: Test text ('wine', 0.001000, 340282346638528859811704183484516925440.000000), result 0, expected 0 mesh.c:3679: Test succeeded inside todo block: Test text ('wine', 0.000000, 1.000000), result 0, expected 0 make: *** [mesh.ok] Error 21 -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: httpapi: add method stub for HttpAddUrl()
by Nikolay Sivov Jan. 11, 2012

Jan. 11, 2012

On 1/11/2012 13:41, Arash Cordi wrote: > + > +ULONG WINAPI HttpAddUrl( HANDLE handle, PCWSTR url, PVOID reserved ) > +{ > + FIXME( "(%p %p %p): stub!\n", handle, url, reserved); > + return ERROR_CALL_NOT_IMPLEMENTED; > +} > + Please use %s format for 'url' so it will be visible in logs.

2 1

What other conferences do Wine people attend?
by Dan Kegel Jan. 11, 2012

Jan. 11, 2012

In the wineconf thread, the question came up: What other conferences people do wine developers/users attend, if any? If you send me the names of the conference(s) you attended in the last two years, I'll summarize for the list.

5 4

Re: cryptui: Use the same capitalization for the same string
by Francois Gouget Jan. 11, 2012

Jan. 11, 2012

On Tue, 10 Jan 2012, André Hentschel wrote: > So that the string needs only one translation in po files - GROUPBOX "Certification path", -1,6,10,245,165, BS_GROUPBOX + GROUPBOX "Certification Path", -1,6,10,245,165, BS_GROUPBOX Unfortunately this goes against the Windows User Experience Interaction Guidelines. Group box labels are supposed to use sentence-style capitalization: http://msdn.microsoft.com/en-us/library/aa511459.aspx But dialog box titles are supposed to use title-style capitalization, hence the case difference: http://msdn.microsoft.com/en-us/library/aa511268.aspx#titles Glossary: * Sentence-style capitalization http://msdn.microsoft.com/en-us/library/aa511441.aspx#SentenceCaps * Title-style capitalization http://msdn.microsoft.com/en-us/library/aa511441.aspx#TitleCaps -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ E-Voting: Those who cast the votes decide nothing. Those who count the votes decide everything.

1 1

Re: [2/5] dinput: SetActionMap saving simple configurations to an .ini file (try 2)
by Vitaliy Margolen Jan. 10, 2012

Jan. 10, 2012

On 01/09/2012 10:18 AM, Lucas Fialho Zawacki wrote: > From: Lucas Fialho Zawacki<lfzawacki(a)gmail.com> > > +static BOOL _write_private_profile_intW(const char *format, WCHAR* section, WCHAR* key, int value, WCHAR* file) I don't think this is such a good idea to mix ASCII and WCHAR parameters. > + static WCHAR path[] = { > + '%','C','o','m','m','o','n','P','r','o','g','r','a','m','F','i','l','e','s','%','\\', > + 'D','i','r','e','c','t','X','\\', > + 'D','i','r','e','c','t','I','n','p','u','t','\\', > + 'U','s','e','r',' ','M','a','p','s','\0'}; Why do you think it should be there in the first place? > + expanded_path = HeapAlloc(GetProcessHeap(), 0, sizeof(WCHAR)*expanded_path_size); No error checking. > +static HRESULT _save_mapping_settings(IDirectInputDevice8W *iface, LPDIACTIONFORMATW lpdiaf, LPCWSTR lpszUsername) > +{ > + static WCHAR mapexists[] = {'M','a','p','E','x','i','s','t','s','\0'}; > + static WCHAR numactions[] = {'N','u','m','A','c','t','i','o','n','\0'}; Should be "static const WCHAR". > + IDirectInputDevice8_GetDeviceInfo(iface,&didev); No error checking. > + va_start(args, format); > + while (1) > + { > + buffer = HeapAlloc(GetProcessHeap(), 0, size); > + if (buffer == NULL) > + break; > + n = vsnprintfW(buffer, size, formatW, args); > + if (n == -1) > + size *= 2; > + else if (n>= size) > + size = n + 1; > + else > + break; > + HeapFree(GetProcessHeap(), 0, buffer); > + } > + va_end(args); You can't do this. It seems to be you have not tested it with initial buffer too small. You have to do va_start & va_end every time you pass "args" to another function. > + > + if (buffer == NULL) return NULL; > + ret = HeapReAlloc(GetProcessHeap(), 0, buffer, sizeof(WCHAR)*(strlenW(buffer)+1) ); > + if (ret == NULL) ret = buffer; Why reallocate? It's pointless. > +extern WCHAR* _get_mapping_path(const WCHAR *device, const WCHAR *username) DECLSPEC_HIDDEN; Would you please drop leading underscore from all of your function names? Vitaliy.

2 2

RFH: Applications that call stuff from DllMain
by Andrew Eikum Jan. 10, 2012

Jan. 10, 2012

This mail is about bugs 28042[1] and 28677[2]. In short, what I'm trying to deal with is buggy applications that make calls to DSound and WinMM from within DllMain(), causing deadlocks. On almost any entry into DSound or WinMM's wave functions, the modules launch a thread to communicate with MMDevAPI. We create a new thread for two reasons. First, to CoInitialize() the thread, which we shouldn't do on a user thread. Second, the MMDevAPI docs say that the device objects should be created and destroyed from the same thread[3], which we can't guarantee if we create them on a user thread (I think dsound currently violates this, actually). Wine holds the loader critical section during calls to DllMain(). However, launching a new thread requires using the loader, and so we hit a deadlock. This is the problem reported by these bugs. While we might be able to perform some of these functions without launching a new thread, I'm not sure that that's a general solution, since we will have to launch a thread at some point. Analysis on Windows 7 shows that DirectSoundEnumerate() does not launch any additional threads, but mixerGetNumDevs() actually does launch a thread, yet the application still launches successfully. So, I'm asking for insights. Should I try hard to avoid launching threads unless absolutely necessary? Is this a known deficiency in the loader, and I should do nothing? Is there some other way to work around this? Thanks, Andrew [1] http://bugs.winehq.org/show_bug.cgi?id=28042 [2] http://bugs.winehq.org/show_bug.cgi?id=28677 [3] http://msdn.microsoft.com/en-us/library/windows/desktop/dd370873%28v=VS.85%…

3 4

Re: winmm: GetCurrentPadding is superfluous while recording.
by Alexandre Julliard Jan. 10, 2012

Jan. 10, 2012

Joerg-Cyril.Hoehle(a)t-systems.com writes: > Hi, > > now winmm recording does not depend on chunking by mmdevapi. > > + if(packet > 0) > + WARN("losing %u frames\n", packet); > That part is interesting. Another approach would have been to check whether > all of GetData could be stuffed into winmm buffers and use ReleaseBuffer(0) if not > (much more complicated in the presence of several buffers). > > As long as winmm supplies enough buffers in advance, that doesn't matter. > > With that in place, the "Fix AudioCaptureClient protocol" patches can be applied on > the winmm side. I have not checked the dsound code. > > I'm sorry winmm:ACMPullData was broken by my former notification patch. I'll have to fix that. > ACMPullData is also not very robust (return; after GetBuffer will prevent any subsequent GetBuffer > with OUT_OF_ORDER). It doesn't work here: ../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so mci.c && touch mci.ok [...] err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 etc. forever -- Alexandre Julliard julliard(a)winehq.org

1 0

[PATCH] wineoss.drv: Fix IAudioRenderClient::{Get,Release}Buffer protocol
by Joerg-Cyril.Hoehle＠t-systems.com Jan. 10, 2012

Jan. 10, 2012

Andrew Eikum wrote: >I think the GetPosition and GetCurrentPadding failures are caused by >using GETOSPACE instead of GETODELAY in GetPosition(). Please write that patch too. It needs good testing to get the start/stop/underrun corner cases right. My hope is that Wine-1.4.0 will have 3 drivers of comparable if not equal quality. What I plan is to submit my render patch with almost all GetPosition tests lifted behind if(winetest_debug>1): render.c:1062: Tests skipped: Rerun with WINETEST_DEBUG=2 for GetPosition tests. This one perhaps should move as well, although it indicates a problem. render.c:1166: Test failed: Position should have been further along... render.c:1227: Test failed: GetCurrentPadding returned 512, should be 0 No idea, please check. render.c:1228: Test failed: Position 142756 at end vs. 143268 submitted frames In shared mode, the end position must be the sum of released frames. In exclusive mode, I've seen some cards return a little less. Your RenderClient patch looks good. Regards, Jörg Höhle

2 1