winetest timeout question
I would like to change the wave tests to always play and record so all code paths can be exercised. A normal run for a single sound card takes over 2 minutes so the test times out before test completion. Has anyone considered changing the timeout logic to be reset every time something is printed? This would allow long tests that periodically output something to run more than 2 minutes. Timeout would only occur 2 minutes after the last output.
Re: Fix winmm's check_position() tests
Robert Reif wrote:
Please revert this patch. It is wrong and produces the following errors
in windows xp:
That's not what I'm seeing here. I have reverted the patch on my local
tree. Then I did 'make crosstest' and I have run the test on Windows XP.
I attached the result to this email.
I get the exact same results on Windows 95, Windows 98 and NT4. Here are
details about the test systems:
* Windows XP SP1
Dell Inspiron 510m
SigmaTel Audio
DirectX 9.0b
* Windows 95
VMWare virtual machine
Creative Ensoniq AudioPCI (VMware)
* Windows 98 OSR2
VMWare virtual machine
Creative Ensoniq AudioPCI (VMware)
DirectX 9.0b
* Windows NT4
VMWare virtual machine
Creative Ensoniq AudioPCI (VMware)
Sometimes in the VMware virtual machines I do get 96000 instead of 96001
for the 96kHz tests. But that does not seem systematic. Maybe that's the
pcm conversion bug you mentioned?
So do you have any idea why we are getting different results? Maybe the
result depends on the individual sound driver and the winmm test should
accept both?
--
Francois Gouget
[EMAIL PROTECTED]
wave.c:519:found 1 WaveOut devices
wave.c:408: 0: "SigmaTel Audio"
(\\?\pci#ven_8086&dev_24c5&subsys_01641028&rev_01#3&61aaa01&0&fd#{6994ad04-93ef-11d0-a3cc-00a0c9223196}\wave)
5.10 (1:100): channels=65535 formats=b support=002c(WAVECAPS_VOLUME
WAVECAPS_LRVOLUME WAVECAPS_SAMPLEACCURATE)
wave.c:417:Playing a 5 seconds reference tone.
wave.c:418:All subsequent tones should be identical to this one.
wave.c:419:Listen for stutter, changes in pitch, volume, etc.
wave.c:317:Playing 5 second 440Hz tone at 22050x 8x1
wave.c:212: Test failed: waveOutGetPosition returned 110251 bytes, should be 110250
wave.c:221: Test failed: waveOutGetPosition returned 110251 samples, should be 110250
wave.c:250:TIME_SMPTE not supported
wave.c:317:Playing 1 second 440Hz tone at 8000x 8x1
wave.c:212: Test failed: waveOutGetPosition returned 8001 bytes, should be 8000
wave.c:221: Test failed: waveOutGetPosition returned 8001 samples, should be 8000
wave.c:250:TIME_SMPTE not supported
wave.c:317:Playing 1 second 440Hz tone at 8000x 8x1 WAVE_FORMAT_DIRECT
wave.c:212: Test failed: waveOutGetPosition returned 8001 bytes, should be 8000
wave.c:221: Test failed: waveOutGetPosition returned 8001 samples, should be 8000
wave.c:250:TIME_SMPTE not supported
wave.c:317:Playing 1 second 440Hz tone at 8000x 8x1 WAVE_MAPPED
wave.c:212: Test failed: waveOutGetPosition returned 8001 bytes, should be 8000
wave.c:221: Test failed: waveOutGetPosition returned 8001 samples, should be 8000
wave.c:250:TIME_SMPTE not supported
wave.c:317:Playing 1 second 440Hz tone at 8000x 8x2
wave.c:212: Test failed: waveOutGetPosition returned 16002 bytes, should be 16000
wave.c:221: Test failed: waveOutGetPosition returned 8001 samples, should be 8000
wave.c:250:TIME_SMPTE not supported
wave.c:317:Playing 1 second 440Hz tone at 8000x 8x2 WAVE_FORMAT_DIRECT
wave.c:212: Test failed: waveOutGetPosition returned 16002 bytes, should be 16000
wave.c:221: Test failed: waveOutGetPosition returned 8001 samples, should be 8000
wave.c:250:TIME_SMPTE not supported
wave.c:317:Playing 1 second 440Hz tone at 8000x 8x2 WAVE_MAPPED
wave.c:212: Test failed: waveOutGetPosition returned 16002 bytes, should be 16000
wave.c:221: Test failed: waveOutGetPosition returned 8001 samples, should be 8000
wave.c:250:TIME_SMPTE not supported
wave.c:317:Playing 1 second 440Hz tone at 8000x16x1
wave.c:212: Test failed: waveOutGetPosition returned 16002 bytes, should be 16000
wave.c:221: Test failed: waveOutGetPosition returned 8001 samples, should be 8000
wave.c:250:TIME_SMPTE not supported
wave.c:317:Playing 1 second 440Hz tone at 8000x16x1 WAVE_FORMAT_DIRECT
wave.c:212: Test failed: waveOutGetPosition returned 16002 bytes, should be 16000
wave.c:221: Test failed: waveOutGetPosition returned 8001 samples, should be 8000
wave.c:250:TIME_SMPTE not supported
wave.c:317:Playing 1 second 440Hz tone at 8000x16x1 WAVE_MAPPED
wave.c:212: Test failed: waveOutGetPosition returned 16002 bytes, should be 16000
wave.c:221: Test failed: waveOutGetPosition returned 8001 samples, should be 8000
wave.c:250:TIME_SMPTE not supported
wave.c:317:Playing 1 second 440Hz tone at 8000x16x2
wave.c:212: Test failed: waveOutGetPosition returned 32004 bytes, should be 32000
wave.c:221: Test failed: waveOutGetPosition returned 8001 samples, should be 8000
wave.c:250:TIME_SMPTE not supported
wave.c:317:Playing 1 second 440Hz tone at 8000x16x2 WAVE_FORMAT_DIRECT
wave.c:212: Test failed: waveOutGetPosition returned 32004 bytes, should be 32000
wave.c:221: Test failed: waveOutGetPosition returned 8001 samples, should be 8000
wave.c:250:TIME_SMPTE not supported
wave.c:317:Playing 1 second 440Hz tone at 8000x16x2 WAVE_MAPPED
wave.c:212: Test failed: waveOutGetPosition returned 32004 bytes, should be 32000
wave.c:221: Test failed: waveOutGetPosition returned 8001 samples, should be 8000
wave.c:250:TIME_SMPTE not supported
wa
Re: Fix winmm's check_position() tests
Francois Gouget wrote: Robert Reif wrote: Please revert this patch. It is wrong and produces the following errors in windows xp: That's not what I'm seeing here. I have reverted the patch on my local tree. Then I did 'make crosstest' and I have run the test on Windows XP. I attached the result to this email. Sometimes in the VMware virtual machines I do get 96000 instead of 96001 for the 96kHz tests. But that does not seem systematic. Maybe that's the pcm conversion bug you mentioned? So do you have any idea why we are getting different results? Maybe the result depends on the individual sound driver and the winmm test should accept both? I compiled the wave test with VC7 on xp pro sp2 using latest platform sdk and dx9 summer update. I have a SB Live!5.1, SB audigy 2, SB 16 pci, and a built in i810. All exhibit the same behavior. My linux setup is an up to date RH 9 smp. Could it be a compiler or vmware issue. I just downloaded a fresh cvs copy and will try it again.
Re: winmm: Fix TIME_SMPTE test
Robert Reif wrote: The only way to test the actual capture and playback code paths is to run in interactive mode. It would be nice to have someone listen to what is played but it is not absolutely necessary to determine if the function calls fail or return bad data. The main goal of interactive tests is to have someone actually listen to the test tones and verify that they are being played correctly: with no stutter and at the correct pitch and volume. This cannot be automated. However it's true that more tests are being performed in interactive mode and that some don't require anyone to listen. So maybe we could have the tests play silence (and not touch the volume) when they are run in non-interactive mode. The capture test can be considered non-interactive already since it does not matter if someone listens to them or not: the capture test records sound but there is no proof that the sound was recorded properly (it's exactly like electronic voting, you vote but you don't know what the machine did). The only way to check that would be to play the sound back and have a human check that what is being played corresponds to what was supposed to be recorded. Of course that supposes actually hooking up a microphone or some other sound source to the soundcard... So the only potential issue is the timeout one... -- Francois Gouget [EMAIL PROTECTED]
Re: appdb dump
Jeremy Newman wrote: This is getting to be a common request. I think what I am going to do is make a script that tars up the appdb every night and puts it up for download. The only table it will not dump will be the userdb, for privacy reasons. I'll email you all again when I have something whipped up. Has there been any action on this front? I haven't heard anything for a while, just checking. -- Joel Konkle-Parker Webmaster [Ballsome.com] E-mail [EMAIL PROTECTED]
Re: winmm: Fix TIME_SMPTE test
The only way to test the actual capture and playback code paths is to run in interactive mode. It would be nice to have someone listen to what is played but it is not absolutely necessary to determine if the function calls fail or return bad data.
Re: winmm: Fix TIME_SMPTE test
Hi Robert,
Robert Reif wrote:
SMPTE support in windows is not a hardware feature. winmm just takes
the byte count read/written and converts it to a different format.
Windows rounds up partial frames (hence ceil). I thought it was
strange but thats what it does.
Which Windows platform did you test this on?
I applied the following patch to the winmm tests and got 'TIME_SMPTE not
supported' on every platform I tested it on.
(the patch is going to be line wrapped here but you get the idea)
Index: wave.c
===
RCS file: /var/cvs/wine/dlls/winmm/tests/wave.c,v
retrieving revision 1.31
diff -u -r1.31 wave.c
--- wave.c 19 Jul 2004 20:08:24 - 1.31
+++ wave.c 19 Jul 2004 22:28:14 -
@@ -241,6 +246,8 @@
(BYTE)(fmod(floor(duration/60), 60)),
(BYTE)(fmod(duration,60)),
(BYTE)(fmod(duration*mmtime.u.smpte.fps, mmtime.u.smpte.fps)));
+else
+trace("TIME_SMPTE not supported\n");
}
There is also an off by one bug in msacm pcm conversions which
triggers on certain conversions.
Could you provide more details? Is this on Windows?
The only way to confirm windows behaviors is to run the winmm test in
interactive mode.
winetest would need to be changes to run it that way and the tests
could take longer than the timeout period when multiple sound cards
are present.
I believe the idea behind winetest is that it should run unattended.
Running interactive tests unattended does not seem to make much sense.
However, providing a way for winetest users to explicitly run it in
interactive mode would be nice.
Could we please run the winmm tests in interactive mode by default
and then make changes if necessary to duplicate windows behavior
rather than just making untested changes. The winmm tests work fine
on my hardware in windows xp as is and also in wine except for the
msacm off by one bug with certain format conversions.
Do you mean that for you waveGetPosition() returns the number of samples
played and not the number plus one on your Windows XP machine? That's
certainly not what I am seeing on my Windows XP, Windows NT4, Windows 98
and Windows 95 machines. Now the winmm tests run successfully on all
these Windows platforms in interactive mode.
--
Francois Gouget
[EMAIL PROTECTED]
Re: winmm: Fix TIME_SMPTE test
SMPTE support in windows is not a hardware feature. winmm just
takes the byte count read/written and converts it to a different format.
Windows rounds up partial frames (hence ceil). I thought it was strange
but thats what it does.
There is also an off by one bug in msacm pcm conversions which triggers
on certain conversions.
The only way to confirm windows behaviors is to run the winmm test in
interactive mode. winetest would need to be changes to run it that way
and the tests could take longer than the timeout period when multiple
sound cards are present.
Could we please run the winmm tests in interactive mode by default
and then make changes if necessary to duplicate windows behavior
rather than just making untested changes. The winmm tests work fine
on my hardware in windows xp as is and also in wine except for the
msacm off by one bug with certain format conversions.
Francois Gouget wrote:
I got failures when running the winmm conformance test in Wine:
wave.c:239: Test failed: waveOutGetPosition returned 0:0:5 1, should
be 0:0:5 0
This test checks that waveOutGetPosition() returns the correct value
when asked for the TIMP_SMPTE position but Wine would systematically
return 1 as the frame instead of 0.
First I tried to check what Windows did in that case but I was not
able to find a Windows version that supports the TIME_SMPTE format
(tried Win95, Win98, NT4, WinXP). This means applications are unlikely
to actually ever use this... maybe this is a 16bit thing.
The reason why Wine always returns 1 in the frame is a combination of
two factors:
* we start from dwPlayedTotal which is always the number of played
samples plus 1. So if we played 1 second at 48000x8x1 we'd get 48004
instead of 48000.
* then convert this into hours, minutes, seconds and the remainder
(8.3e-5) gives us the frames. But we use ceil() which converts that to 1!
So I just modified each driver's implementation to use round() instead
of ceil(). IMO ceil() is the wrong tool for the job. With floats,
after a few operations you quickly end up with 1e-30 or -1e-30, but
never with big round 0. So ceil() is going to give you 0 or 1
quasi-randomly. At least round() behaves sanely.
Maybe we should also remove that one extra sample but given I have not
been able to confirm the Windows behavior I'd rather not worry about it.
I'm willing to change my mind if someone feels strongly about it or
can provide more data about how Windows really behaves.
Changelog:
* dlls/winmm/winealsa/audio.c
dlls/winmm/winearts/audio.c
dlls/winmm/wineaudioio/audio.c
dlls/winmm/winejack/audio.c
dlls/winmm/winenas/audio.c
dlls/winmm/wineoss/audio.c
Francois Gouget <[EMAIL PROTECTED]>
Use round() instead of ceil() in wodGetPosition(TIME_SMPTE).
Fixes the corresponding winmm conformance test.
Index: dlls/winmm/winealsa/audio.c
===
RCS file: /var/cvs/wine/dlls/winmm/winealsa/audio.c,v
retrieving revision 1.45
diff -u -r1.45 audio.c
--- dlls/winmm/winealsa/audio.c 14 Jun 2004 16:59:34 - 1.45
+++ dlls/winmm/winealsa/audio.c 16 Jul 2004 23:11:24 -
@@ -1873,7 +1873,7 @@
time -= lpTime->u.smpte.min * 60;
lpTime->u.smpte.sec = time;
time -= lpTime->u.smpte.sec;
- lpTime->u.smpte.frame = ceil(time * 30);
+ lpTime->u.smpte.frame = round(time * 30);
lpTime->u.smpte.fps = 30;
TRACE("TIME_SMPTE=%02u:%02u:%02u:%02u\n",
lpTime->u.smpte.hour, lpTime->u.smpte.min,
Index: dlls/winmm/winearts/audio.c
===
RCS file: /var/cvs/wine/dlls/winmm/winearts/audio.c,v
retrieving revision 1.20
diff -u -r1.20 audio.c
--- dlls/winmm/winearts/audio.c 15 Jun 2004 20:25:11 - 1.20
+++ dlls/winmm/winearts/audio.c 16 Jul 2004 23:11:36 -
@@ -1427,7 +1427,7 @@
time -= lpTime->u.smpte.min * 60;
lpTime->u.smpte.sec = time;
time -= lpTime->u.smpte.sec;
- lpTime->u.smpte.frame = ceil(time * 30);
+ lpTime->u.smpte.frame = round(time * 30);
lpTime->u.smpte.fps = 30;
TRACE("TIME_SMPTE=%02u:%02u:%02u:%02u\n",
lpTime->u.smpte.hour, lpTime->u.smpte.min,
Index: dlls/winmm/wineaudioio/audio.c
===
RCS file: /var/cvs/wine/dlls/winmm/wineaudioio/audio.c,v
retrieving revision 1.12
diff -u -r1.12 audio.c
--- dlls/winmm/wineaudioio/audio.c 1 Jun 2004 20:22:11 - 1.12
+++ dlls/winmm/wineaudioio/audio.c 16 Jul 2004 23:11:48 -
@@ -1121,7 +1121,7 @@
time -= lpTime->u.smpte.min * 60;
lpTime->u.smpte.sec = time;
time -= lpTime->u.smpte.sec;
- lpTime->u.smpte.frame = ceil(time * 30);
+ lpTime->u.smpte.frame = round(time * 30);
lpTime->u.smpte.fps = 30;
TRACE("TIME_SMPTE=%02u:%02u:%02u:%02u\n",
lpTime->u.smpte.hour, lpTime->u.smpte.min,
Index: dlls/winmm/winejack/audio.c
===
RCS file: /var/cvs/wine/dll
Re: wine-pthread working on MacOSX
emmanuel maillard <[EMAIL PROTECTED]> writes: > This patch remove granularity check in NtAllocateVirtualMemory for > Darwin, because teb can be alloc at > address < granularity_mask (0x) This must be avoided, nothing should be allocated below 64K, the Windows API depends on that. You probably need to adapt the memory reservation code to reserve the low 64K on Darwin. -- Alexandre Julliard [EMAIL PROTECTED]
Re: D3D8_GetCreationParameters fix
Hi, From what I'm hearing, there is some code that is usefull and not part of the Wine project. Does it worth adding it to Wine so every one can use it to ease debugging of apps under Windows? Bye, Christian From Jonathan This would be great but how do you do with COM objects. What did you do for your direct3d hooking. I remember someone on the ReactOS team gave me the hook related stuff. (I cant remember who) What I do is to modify the target to load the hook dll instead of the normal dll. The hook dll then loads the normal dll and hooks whatever direct3d functions you like... Lionel Ulmer wrote: This would be great but how do you do with COM objects. What did you do for your direct3d hooking. Well, this is a pet project I had for a long time (and maybe will do the day I will have a faster PC and QEMU runs any Windows version in a reasonnable speed :-) ). Basically, take the Wine DirectX framework (i.e. all the COM object methods + TRACEing) and just use it to 'wrap' the real API. The only stuff to be careful are the functions returning new COM objects (either creation functions or QueryInterface) and callbacks. A part from that, it's something that is definitely doable in a day hacking session :-) Lionel
Re: build problem
Stefan Leichter <[EMAIL PROTECTED]> writes: > My computer has a cvs (source) tree and the build tree. When i make > changes to test something, i copy the source file to be changed for > the source tree into the build tree and modify it. After this i run > configure, make depend, make and make install in the build tree to get > the changes into the wine binary. > > If a c-source file or a header file exists in the build tree it ist > used instead of the file in the source tree. Spec files in the build > tree are ignored. They are always used from the source tree. Therefore > i have to edit the Makefile in the build tree to use the modified spec > file, or like the dll.so file by hand. > > Hope my problem is explained clearer now. Do i use an undocumented feature? Yes, that's not how you are supposed to use build trees. The build tree should contain only generated files, all the sources should be in the source tree. It won't work right to have sources in both places, not only because of the spec files, dependencies also won't be correct include files may not always be included from where you expect, etc. -- Alexandre Julliard [EMAIL PROTECTED]
Re: urlmon missing InternetSecurityManager
On Mon, Jul 19, 2004 at 05:19:36PM +0200, Jeroen Janssen wrote: > Any idea why this script is not in the wine tree somewhere? (tools/?) Because it was an unmanageable Python hack that worked for me after a lot of tweakings (for DirectX and QUARTZ). I can see if I can get something clean out of it for submission (but I do not even remember what the inputs were :-) ). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Reimplementation of CryptAcquireContextA
Am Montag, 19. Juli 2004 02:47 schrieb Robert Shearman: > Michael Jung wrote: > >Hello, > > > >The original CryptAcquireContextA had some issues with memory management > >in failure conditions, resulting in heap corruption under certain > >cirumstances. I've reimplemented this function, checking behaviour against > >Windows XP Prof. There is also a unit test included in the patch, which > >tests CryptAcquireContext and successfully runs to completion on > >both Windows XP and Wine. The patch looks worse than it is, since diff > >believes to have found similarities between my new implementation and the > >original CryptAcquireContextA. > > Alexandre has already modified CryptAcquireContextA to fix the original > problem, but I'll comment on the patch anyway. ... > Two comments: > 1. This seems like overkill - a new function *and* a new structure to go > with it? > 2. Use CRYPT_Free instead of HeapFree in case someone in the future > changes the memory to routines to some non-Heap* (or remove the CRYPT > memory routines altogether) > > > ... > > Your patch does highlight one issue though - we should be freeing all of > the resource from one path, not multiple paths and the best way to do > this is how it is currently done - by using a goto. > Maybe we could simplify the function by putting chunks into new > functions, but certainly not a new function just to release local > resources. > > Rob Hi Rob, The original CryptAcquireContextA had a couple of memory management issues and Alexandre's patch only takes care of one. Furthermore, the original implementation does not comply to Windows behaviour regarding error reporting. The unit test given in the patch succesfully runs to completion on both Windows XP Professional and Wine, but only with the new CryptAcquireContext. The function and the structure are used to keep the CryptAcquireContext function body more readable. As you pointed out, this could also be achieved with goto's and a labeled cleanup section (Though not as compact, since you still would have to do a "SetLastError(..); goto error;", which requires an additional pair of curly braces ;) ). Personally I don't like goto's, but this is perhaps a position too academic. So if the wine community favours the goto approach, I will be happy to modify the code. The patch uses the HeapAlloc function only for memory blocks, which are completely memory managed inside CryptAcquireContext. This means that the implementation of CRYPT_Free is irrelevant here. As far as I understand it, HeapAlloc is the way to go in new code. Am I correct here? Since I'm new to wine, I don't have a firm understanding of the coding conventions. Could some more people comment on the given patch, please? This would help me to get a better picture. Thanks and greetings, Michael
Re: urlmon missing InternetSecurityManager
>>Are there any (wine) pointers on implementing a new (stubbed) COM >> interface? >> >> > > You will need to update the corresponding urlmon.h header file too, so > that it can be used by C code. You can do this by running "make idl" in > the wine/include/ directory. Yes, I expected something like that too.. On a side note, why is this not done during the "regular make" process? > Lionel Ulmer had a script to create a stubbed out COM interface, so > maybe he could give you the script or create the interface for you. Any idea why this script is not in the wine tree somewhere? (tools/?) --- Jeroen
Re: Scrollbars, an application bug or a wine regression ? (#2314)
Am 16.07.2004 um 15:25 schrieb Dmitry Timoshkov: "Nicolai Kuntze" <[EMAIL PROTECTED]> wrote: I have the program online with some help how to get it started and how to get the error/problem. I hope you have seen this. Does this help you? I try to get from the developer some test case but I can not promise anything. If I can't get an .exe or a code snippet (with a description how it's intended to behave) showing the problem I can't do anything to understand and eventually to solve the problem. -- Dmitry. Today I got some modified code snipplet: case WM_PAINT: PAINTSTRUCT MalInfo; BeginPaint( hwnd, &MalInfo); EndPaint( hwnd, &MalInfo); HDC hdc= GetDC( hwnd); BitBlt( hdc, 0, 20, doublebuffersize.right-doublebuffersize.left, doublebuffersize.bottom-doublebuffersize.top, doublebufferHdc, 0, 0, SRCCOPY); ReleaseDC( (HWND)ViewGetHWND(), hdc); I hope this helps. Yours, Nicolai Diese Nachricht wurde auf Viren und andere gefaehrliche Inhalte sowie Spam untersucht.
Re: Reimplementation of CryptAcquireContextA
Am Montag, 19. Juli 2004 02:47 schrieb Robert Shearman: > Michael Jung wrote: > >Hello, > > > >The original CryptAcquireContextA had some issues with memory management > >in failure conditions, resulting in heap corruption under certain > >cirumstances. I've reimplemented this function, checking behaviour against > >Windows XP Prof. There is also a unit test included in the patch, which > >tests CryptAcquireContext and successfully runs to completion on > >both Windows XP and Wine. The patch looks worse than it is, since diff > >believes to have found similarities between my new implementation and the > >original CryptAcquireContextA. > > Alexandre has already modified CryptAcquireContextA to fix the original > problem, but I'll comment on the patch anyway. > ... > > Two comments: > 1. This seems like overkill - a new function *and* a new structure to go > with it? > 2. Use CRYPT_Free instead of HeapFree in case someone in the future > changes the memory to routines to some non-Heap* (or remove the CRYPT > memory routines altogether) > > > ... > > Your patch does highlight one issue though - we should be freeing all of > the resource from one path, not multiple paths and the best way to do > this is how it is currently done - by using a goto. > Maybe we could simplify the function by putting chunks into new > functions, but certainly not a new function just to release local > resources. > > Rob Hi Rob, The original CryptAcquireContextA had a couple of memory management issues and Alexandre's patch only takes care of one. Furthermore, the original implementation does not comply to Windows behaviour regarding error reporting. The unit test given in the patch succesfully runs to completion on both Windows XP Professional and Wine, but only with the new CryptAcquireContext. The function and the structure are used to keep the CryptAcquireContext function body more readable. As you pointed out, this could also be achieved with goto's and a labeled cleanup section (Though not as compact, since you still would have to do a "SetLastError(..); goto error;", which requires an additional pair of curly braces ;) ). Personally I don't like goto's, but this is perhaps a position too academic. So if the wine community favours the goto approach, I will be happy to modify the code. The patch uses the HeapAlloc function only for memory blocks, which are completely memory managed inside CryptAcquireContext. This means that the implementation of CRYPT_Free is irrelevant here. As far as I understand it, HeapAlloc is the way to go in new code. Am I correct here? Since I'm new to wine, I don't have a firm understanding of the coding conventions. Could some more people comment on the given patch, please? This would help me to get a better picture. Thanks and greetings, Michael
problem in dsound with DirectSoundCreate
hi all,
iÂm trying to get the djing app "native instruments traktor dj studio"
to work under recent wine versions. iÂm running fc2 with kernel
2.6.6.1-435 on a dell laptop. when only using one stereo channel, the
app really runs fine, but for djing you need monitor support, which
means to use 4 channels of a quadrophonic sound card (my one is a audigy
nx, but same for the intenal card). the means using the ds subsystem,
since mm is not capable of using 4 channels..
i recently posted this question to wine-users, but i traced the error a
bit more and think its more of interest to developers. if you guys can
give me some hints one the sourcecode, may be iÂm able to fix the
problem..
the problem is:
djstudio when started up the first time wants to know which device and
which driver to use. therefor a dropdown lists pops up, wher the devices
and the available drivers are listed (eg. mm, ds, asio, etc..) when
choosing a driver i can then assign audio channels for monitoring and
master.
now, with wine and wineoss driver djstudio correctly lists the
audio-devices available, and with mm two channels are provided for
either the master or monitor audio channel. but when i choose the "ds
driver" no channels are supported. i think the problem is located in the
lowlevel wineoss driver, where DirectSoundCreate is something confusing
with GUIDs.
detail:
wine-20040615, WINEDEBUG=trace+dsound,warn+dsound lists
<--snip-->
trace:dsound:DirectSoundEnumerateA calling
lpDSEnumCallback(NULL,"Primary Sound Driver","wineoss.drv",0x556efb1c)
trace:dsound:DirectSoundEnumerateA calling
lpDSEnumCallback({bd6dd71a-3deb-11d1-b171-00c04fc2},"SigmaTel
STAC9750/51","wineoss.drv",0x556efb1c)
trace:dsound:DirectSoundCaptureEnumerateA (0x60ce54,0x556efb1c)
trace:dsound:GetDeviceID (0x55bd1868,0x556ef818)
trace:dsound:DirectSoundCaptureEnumerateA calling
lpDSEnumCallback(NULL,"Primary Sound Capture
Driver","wineoss.drv",0x556efb1c)
trace:dsound:DirectSoundCaptureEnumerateA calling
lpDSEnumCallback({bd6dd71b-3deb-11d1-b171-00c04fc2},"SigmaTel
STAC9750/51","wineoss.drv",0x556efb1c)
trace:dsound:DirectSoundCreate8
({58d80060-2a50-5ba7-b171-00c04038a75b},0x5ba71010,(nil))
trace:dsound:setup_dsound_options appname =
[TraktorDJStudio2Demo.exe\dsound]
warn:dsound:setup_dsound_options ds_hw_accel = Emulation (default=Full)
trace:dsound:GetDeviceID (0x556ef818,0x556edb84)
trace:dsound:DirectSoundCreate8 expecting GUID
{58d80060-2a50-5ba7-b171-00c04038a75b}.
trace:dsound:DirectSoundCreate8 got GUID
{bd6dd71a-3deb-11d1-b171-00c04fc2} for wod 0.
warn:dsound:DirectSoundCreate8 No device found matching given ID -
trying with default one !
<--snap-->
trace:dsound:IDirectSoundImpl_SetCooperativeLevel
(0x55241ce8,00010024,2(DSSCL_PRIORITY))
fixme:dsound:IDirectSoundImpl_SetCooperativeLevel level=DSSCL_PRIORITY
not fully supported
<--snap II>
as you can see the internal hw device "SigmaTel STAC9750/51" of my
laptop is listed. then tow problems occur
1) DirectSoundCreate8 receives a wrong GUID (whatever that meens??)
2) SetCooperativeLevel level is not fully supported (whatever that
meens??)
in wine-20040716 the SetCooperativeLevel seems to be fixed and
DirectSoundCreate8 switched to DirectSoundCreate but also recieves a
wrong GUID, which i think thats the main reason traktor wonÂt list
channels. i think, traktor is checking, if the device is really there
now, i read something about a related problem
(http://www.winehq.org/hypermail/wine-devel/2004/05/0022.html)
the patch, which is in the actual sourcecode,
...
This->pDirectSound = (IDirectSound*) pDirectSound;
IDirectSound_AddRef((LPDIRECTSOUND) This->pDirectSound);
} else {
DirectSoundCreate8(NULL, (LPDIRECTSOUND8*) &This->pDirectSound, NULL);
...
i think always trys to get the default device with the NULL paramter..
am i right, i dont really know??
please, can you help i some way, why the GUID is wrong (maybe my setup) or where to
experiment with the sourcecode ??
thankx in advance&all the best
christoph
ps: the djstudio demo is available at www.nativeinstruments.com
--
dipl.-ing. christoph kunz
fraunhofer institut fuer arbeitswirtschaft und organisation
competence center softwaretechnik
nobelstrasse 12
d-70569 stuttgart
germany
fon: +49 (0)711 - 970 2314
fax: +49 (0)711 - 970 2300
mail: [EMAIL PROTECTED]
icq#: 49335597
web: http://www.iao.fhg.de
pgp#: [EMAIL PROTECTED]
Re: urlmon missing InternetSecurityManager
Jeroen Janssen wrote: Hello, It seems urlmon is missing a (stubbed) IInternetSecurityManager Interface (see also http://msdn.microsoft.com/workshop/security/szone/reference/ifaces/iinternetsecuritymanager/iinternetsecuritymanager.asp ). Since I am new to this, I was wondering how I can create a stubbed implementation. As far as I can tell I need to : * update the urlmon.idl (add IInternetSecurityManager) * create a stubbed implemenation in dlls/urlmon/; making sure the stubbed interface also gets registered during 'wineprefixcreate'. Are there any (wine) pointers on implementing a new (stubbed) COM interface? You will need to update the corresponding urlmon.h header file too, so that it can be used by C code. You can do this by running "make idl" in the wine/include/ directory. Lionel Ulmer had a script to create a stubbed out COM interface, so maybe he could give you the script or create the interface for you. However, given the relatively small number of methods in IInternetSecurityManager it might be just as easy to create it by hand. Rob
Re: dsound test: Remove unneeded Caps/3D test
On Mon, 19 Jul 2004, Francois Gouget wrote: > On Sun, 18 Jul 2004, Robert Reif wrote: > > > Please don't apply this patch. The point of the test is to test the > > QueryInterface reference > > counting which you just removed. Please just fix the flag bug and not > > remove the point of > > the test. > > We still have: > ref=IDirectSoundBuffer_AddRef(secondary); > > What does this one add to it? > ref=IDirectSound3DBuffer_AddRef(buffer3d); Well, I just realized that adding CTRL3D for this test does not impact the buffers we use for playing the test tones so adding CTRL3D is fine by me. disregard my previous message then. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ A black hole is just God dividing by zero.
Re: Fix crash in dsound test
On Mon, 19 Jul 2004, Ferenc Wagner wrote: [...] > Can you (cross)build the directsound tests? My toolchain is > far too old, but yours could cope. If it/they can, we > should include them into winetest, although interactive > testing would remain unavoidable. Hmm, maybe winetest > should explicitly reset WINETEST_INTERACTIVE and the other > variables... It should probably do so. But maybe it could also have an option to explicitly let you run a specific test in interactive mode? That way it's still a single executable to get all the up-to-date tests, but users can also do the interactive tests if they want. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont \xE9t\xE9 remplac\xE9s par de nouveaux.
Re: Fix crash in dsound test
Hi Robert, Robert Reif wrote: How did this fail in windows. Since it doesn't crash with wine, wine is doing something wrong. Lets try to figure out what is wrong and correct wine to have the same behavior as windows or at least notify someone that something is wrong. Sorry, I should have added a DSERR_UNINITIALIZED error check. But I see your "dsound initialization patch" fixes this oversight and also the DirectSound problem in Wine. Thanks. Is anyone working on getting direct sound into the windows port of our regression tests? Well, I didn't work on this directly but I tried to get executables for testing on Windows. Once I grabbed the special 'Wine MinGW' libraries I was able to compile it fine with MinGW so that's one way. I also tried to compile it with VC6 on Windows but I had less luck with that. I also had problems compiling the test on Windows using VC6+latest Win32 SDK+DirectX9.0. But your "windows compile patch" fixed these problems. So I think there's no obstacle to putting the DirectSound tests in winetest. The only problem with this test is that it requires DirectX 9.0. It's annoying because: * it means we cannot test the behavior of older versions of DirectX. * DirectX 9.0 cannot be installed on some Windows platforms, notably Windows 95 and NT4. So it would be cool if the dependencies on DirectX 9 could be made 'soft'. -- Francois Gouget [EMAIL PROTECTED]
Re: Fix crash in dsound test
Robert Reif <[EMAIL PROTECTED]> writes: > How did this fail in windows. Since it doesn't crash with > wine, wine is doing something wrong. Lets try to figure > out what is wrong and correct wine to have the same > behavior as windows or at least notify someone that > something is wrong. > > Is anyone working on getting direct sound into the windows > port of our regression tests? > > Francois Gouget wrote: > >> Changelog: >> >> * dlls/dsound/tests/dsound.c >> >>Francois Gouget <[EMAIL PROTECTED]> >>Call IDirectSound::Initialize() as per MSDN before using the >>DirectSound object. Fixes a crash on Windows. Hi Kevin, hi Paul, Can you (cross)build the directsound tests? My toolchain is far too old, but yours could cope. If it/they can, we should include them into winetest, although interactive testing would remain unavoidable. Hmm, maybe winetest should explicitly reset WINETEST_INTERACTIVE and the other variables... -- Feri.
Re: urlmon missing InternetSecurityManager
Jeroen Janssen wrote: Since I am new to this, I was wondering how I can create a stubbed implementation. As far as I can tell I need to : * update the urlmon.idl (add IInternetSecurityManager) right * create a stubbed implemenation in dlls/urlmon/; making sure the stubbed interface also gets registered during 'wineprefixcreate'. right... though you should only need to add an implementation of URLMON_DllRegisterServerEx to make that work, assuming that wine.inf already tries to register urlmon.dll Are there any (wine) pointers on implementing a new (stubbed) COM interface? It's nice to have a test program (usually built on a windows machine) to test your new interface. Make sure you get the right number of methods in the right order, with the right calling convention and arguments. You need to implement IUnknown manually. You probably want to reference another piece of code that already implements a COM interface... there's plenty in dlls/shell32 and dlls/ole32. (eg. dlls/shell32/shelllink.c) have fun, Mike
urlmon missing InternetSecurityManager
Hello, It seems urlmon is missing a (stubbed) IInternetSecurityManager Interface (see also http://msdn.microsoft.com/workshop/security/szone/reference/ifaces/iinternetsecuritymanager/iinternetsecuritymanager.asp ). Since I am new to this, I was wondering how I can create a stubbed implementation. As far as I can tell I need to : * update the urlmon.idl (add IInternetSecurityManager) * create a stubbed implemenation in dlls/urlmon/; making sure the stubbed interface also gets registered during 'wineprefixcreate'. Are there any (wine) pointers on implementing a new (stubbed) COM interface? Best regards, Jeroen Janssen
Re: dsound test: Remove unneeded Caps/3D test
On Sun, 18 Jul 2004, Robert Reif wrote: > Please don't apply this patch. The point of the test is to test the > QueryInterface reference > counting which you just removed. Please just fix the flag bug and not > remove the point of > the test. We still have: ref=IDirectSoundBuffer_AddRef(secondary); What does this one add to it? ref=IDirectSound3DBuffer_AddRef(buffer3d); -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ "Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" -- Linus Torvalds
Re: build problem
Alexandre Julliard wrote: Stefan Leichter <[EMAIL PROTECTED]> writes: My problem is related to 'out of tree builds'. When i have a changed spec file for a dll in the build tree it does not get used. The spec file from the source tree is used. Can this be fixed? The spec file is source so it should be in the source tree, I don't see anything to fix here. What are you trying to do? My computer has a cvs (source) tree and the build tree. When i make changes to test something, i copy the source file to be changed for the source tree into the build tree and modify it. After this i run configure, make depend, make and make install in the build tree to get the changes into the wine binary. If a c-source file or a header file exists in the build tree it ist used instead of the file in the source tree. Spec files in the build tree are ignored. They are always used from the source tree. Therefore i have to edit the Makefile in the build tree to use the modified spec file, or like the dll.so file by hand. Hope my problem is explained clearer now. Do i use an undocumented feature? Bye Stefan
