August 2005 - Wine-Devel - list.winehq.org

Re: WINEALSA: comment on unexpected shrinking of mmap-buffer (resend)

by Robert Reif

Alex Villacís Lasso wrote: > Alex Villacís Lasso wrote: > >> >>> The good news: the patch sort of works (in my setup, at least, with >>> Fedora Core 4). All the games I have (Japanese RPGs) now have smooth >>> sound, unless the CPU load is too high. >>> The bad news: the patch does nothing to make the dsound tests pass >>> in Wine (but they were already failing before the patch :-) >> >> >> >> In a previous post, I commented about DirectSound tests failing when >> ALSA is used with full hardware acceleration. Now I know the reason why. >> >> As far as I can glean from the code, DirectSound is supposed to >> report the application several properties of the sound system, >> including the size of the hardware buffer. This hardware buffer is >> queried by the snd_hw_params_get_buffer_size(), and is then converted >> from frame units to bytes. Then the application, or in this case, the >> test, expects the buffer size to remain constant for each and every >> hardware buffer created, regardless of requested format. Only this >> assertion fails in ALSA. For example, the capability query causes the >> following output to be shown: >> >> trace:wave:DSDB_CreateMMAP format=U8 frames=11025 channels=2 >> bits_per_sample=8 bits_per_frame=16 >> trace:wave:DSDB_CreateMMAP created mmap buffer of 11025 frames (22050 >> bytes) at 0x7c0fd100 >> >> This reported size (22050 bytes) remains constant as long as the >> request is for U8 format with 2 channels (although the mmap address >> jumps between three different values in my setup; this may or may not >> be relevant). However, as soon as the requested format changes, the >> trace shows the following: >> >> trace:wave:DSDB_CreateMMAP format=S16_LE frames=3763 channels=2 >> bits_per_sample=16 bits_per_frame=32 >> trace:wave:DSDB_CreateMMAP created mmap buffer of 3763 frames (15052 >> bytes) at 0x7c0fd6b8 >> >> There goes a fourth mmap address, but the truly interesting thing is >> that the buffer size also changes, and no longer matches the >> previously reported size of 22050 bytes. The test then goes and plays >> a 5-second sound with the (now incorrect) buffer size of 22050 bytes, >> not noting that the reported position is wrapping around at 15052 bytes: >> >> ds3d.c:431: Playing 5 second 440Hz tone at 11025x16x2 >> >> ... >> >> trace:dsound:DSOUND_PrimaryGetPosition (0x7fe03ab8,0x7fa6fa80,(nil)) >> trace:wave:IDsDriverBufferImpl_GetPosition hw_ptr=0x00000000, >> playpos=0, writepos=-1, mmap_buflen_bytes=15052 >> trace:dsound:DSOUND_PrimaryGetPosition playpos = 0, writepos = 0 >> (0x7fe03ab8, time=1913) >> trace:dsound:PrimaryBufferImpl_GetCurrentPosition playpos = 0, >> writepos = 0 (0x7fe03ab8, time=1913) >> ds3d.c:230:buf size=22050 last_play_pos=0 play_pos=0 played=0 / >> 220500, fraction_played=0 >> ds3d.c:248:offset=15052 free=6998 written=15052 / 220500 >> >> ... >> ds3d.c:230:buf size=22050 last_play_pos=10296 play_pos=11700 >> played=11700 / 220500, fraction_played=1404 >> ds3d.c:248:offset=10296 free=1404 written=32346 / 220500 >> ds3d.c:230:buf size=22050 last_play_pos=11700 play_pos=13104 >> played=13104 / 220500, fraction_played=1404 >> ds3d.c:248:offset=11700 free=1404 written=33750 / 220500 >> ds3d.c:230:buf size=22050 last_play_pos=13104 play_pos=14508 >> played=14508 / 220500, fraction_played=1404 >> ds3d.c:248:offset=13104 free=1404 written=35154 / 220500 >> ds3d.c:230:buf size=22050 last_play_pos=14508 play_pos=860 >> played=22910 / 220500, fraction_played=8402 >> ds3d.c:248:offset=14508 free=8402 written=36558 / 220500 >> >> Please note that the play_pos wrapped from 14508 to 860 because it >> exceeded 15052 bytes, but the test assumes it wrapped around at 22050 >> bytes, so it miscalculates the fraction_played, advancing it at an >> abnormally fast rate. That is how the following result ensues: >> >> trace:dsound:DSOUND_PrimaryGetPosition playpos = 176, writepos = 0 >> (0x7fe03ab8, time=5366) >> trace:dsound:PrimaryBufferImpl_GetCurrentPosition playpos = 176, >> writepos = 0 (0x7fe03ab8, time=5366) >> ds3d.c:230:buf size=22050 last_play_pos=13824 play_pos=176 >> played=220676 / 220500, fraction_played=8402 >> ds3d.c:237:all the samples have been played, stopping... >> ds3d.c:279:stopping playback >> trace:dsound:PrimaryBufferImpl_Stop (0x7fe143b8) >> ds3d.c:628: Test failed: The sound played for 3453 ms instead of 5000 ms >> >> Many other tests with formats other than U8, 11025Hz fail for the >> same reason. Any other DirectSound application that reuses the buffer >> size as the test does will fail in the same way (music mixing up and >> prematurely stopping). However, I am to understand that this test >> passes on Windows, in all versions. >> >> Now that I have found the issue, I ask for help in suggesting a >> proper fix. I think that the ALSA implementation used to have a >> separate buffer from which samples were copied into the hardware >> buffer, but this implementation was scrapped for some reason (and I >> think, without re-running the ALSA tests). So I tried using >> snd_hw_params_set_buffer_size() - it fails to set the buffer size to >> the previously reported size. So I am still thinking about this. Any >> comments or suggestions for fixing this will be greatly appreciated. >> >> BTW, does the DirectSound API allow the application to access the >> hardware mmap directly (that is, not just by specifying the buffer to >> be played)? If not, one possible solution would be to remember the >> first reported buffer size, and wrap the *reported* position around >> at that buffer size, even when the ALSA playback uses the real buffer >> size. However, when I tried to do this (by hardcoding 22050 as a >> wraparound value, just as a test), Wine promptly crashed, so I need >> more insight into this. >> >> Alex Villacís Lasso >> > Resending because previous attempt probably was rejected due to > gigantic attachment (my bad). Only the primary buffer supports hardware acceleration. The secondary buffer(s) are implemented in software and mixed into the primary buffer. The formats (mono/stereo, 8/16 bit samples, and sample rate) of the primary and secondary buffers are totally independent and can be anything. One of the dsound tests keeps the primary buffer format constant and iterates through all secondary buffer formats and another keeps the secondary buffer format constant and iterates through all possible primary formats. This is probably what you are seeing. The secondary buffer format has nothing to do with what is sent to the hardware.

Aug. 14, 2005

Re: AppDB - set default comments mode to threaded for new users

by Tony Lambregts

Chris Morgan wrote: > Chris Morgan <cmorgan(a)alum.wpi.edu> > include/user.php > Set default comments mode to threaded for new users > Index: include/user.php > =================================================================== > RCS file: /opt/cvs-commit/appdb/include/user.php,v > retrieving revision 1.46 > diff -u -r1.46 user.php > --- include/user.php 14 Aug 2005 18:49:21 -0000 1.46 > +++ include/user.php 14 Aug 2005 19:32:59 -0000 > @@ -88,7 +88,11 @@ > $sValues = "({$aInsert['VALUES']}, password('".$sPassword."'), NOW(), NOW() )"; > > query_appdb("INSERT INTO user_list $sFields VALUES $sValues", "Error while creating a new user."); > - return $this->login($sEmail, $sPassword); > + > + $retval = $this->login($sEmail, $sPassword); > + $this->setPref("comments:mode", "threaded"); /* set the users default comments:mode to threaded */ > + > + return $retval; > } > } > Looks good to me... -- Tony Lambregts

Aug. 14, 2005

Re: MSHMTL: Added QueryStatus implementation

by Saulius Krasuckas

* On Sun, 14 Aug 2005, Jacek Caban wrote: > * Saulius Krasuckas wrote: > > > > Is something like this OK? I have "borrowed" boolean variable > > expect_SetActiveObject_active. > > Yes, it looks good. Does that mean by a chance it can to wine-patches? :-)

Aug. 14, 2005

Wine book

by Christian Britz

Hi, some days ago someone wrote a mail to this list regarding a book that he or she is writing about wine. Unfortunately I lost this mail, could the person please contact me privately? Regards, Christian

Aug. 14, 2005

Re: PATCH: GlobalAddAtomA check for invalid ptr

by Felix Nawothnig

Marcus Meissner wrote: >>Yes, but please don't use the IsBad* functions, use a proper exception >>handler. > Next try, is this what you imagined. The reason for using an exception handler is thread safety - to achieve that you have to put it around the ATOM_AddAtomA call. Felix

Aug. 14, 2005

Re: MSHMTL: Added QueryStatus implementation

by Jacek Caban

Saulius Krasuckas wrote: >* On Sun, 14 Aug 2005, Jacek Caban wrote: > > >>I'm not sure if it is a correct fix. Although it avoids crashes, >>much less functionality of QueryStatus is tested. Before >>your patch all possible commands were tested. >> >> > >This is true only for nt family windows. :-P >On 9x test function exits on an exception. > > As I wrote before, it'll be probably true for 9x family after UIActivate succeeded. > > >>it seems to be a case similar to crashes on xp while HTMLDocument is not >>active in place. In this case it is not active in place because >>UIActivate fails. Looking at the test results, UIActivate is a problem >>on every win 9x and causes most tests to fail. So first UIActivate >>should be fixed and then, if this problem remains, we'll be sure that >>your fix is correct. >> >> > >I don't understand much in all this OLE/In-Place stuph, so I agree, but >still I doubt this would be a sufficient to proof my patch is correct. >:-] > > > >>Presently if you want to make this test not to crash, you may disable >>IOleCommand tests if UIActivate fails. >> >> > >I will try, but what should be done with this (inside test_HTMLDocument)? > >| OLECMD cmd[2] = { >| {OLECMDID_OPEN, 0xf0f0}, >| {OLECMDID_GETPRINTTEMPLATE+1, 0xf0f0} >| }; >| >| hres = IOleCommandTarget_QueryStatus(cmdtrg, NULL, 2, cmd, NULL); >| ok(hres == OLECMDERR_E_NOTSUPPORTED, >| "QueryStatus failed: %08lx, expected OLECMDERR_E_NOTSUPPORTED\n", hres); > > It should be disabled as well. >Or IOW, why first call generates exception on OLECMDID_OPEN command while >second do not? > > >| hres = IOleCommandTarget_QueryStatus(cmdtrg, NULL, 2, cmd, NULL); >| hres = IOleCommandTarget_QueryStatus(cmdtrg, &IID_IHTMLDocument2, 2, cmd, NULL); > >OLECMDID_OPEN seems to be supported at least on winME. I am curious, why? > > > The second call returns after checking that IID_IHTMLDocument2 is not a valid command group id and it doesn't have to check anything else like the current state of HTMLDocument. >>My guess is that it requires to be loaded before a call to UIActivate, >> >> > >What do you exactly mean by "it"? > > HTMLDocument > > >>so the attached patch might help (even if so, a few other tests will >>fail, but currently the most interesting is UIActivate), >> >> > >No, the patch didn't help. > > > OK, I'll take a look at this today or tomorrow. > Is something like this OK? I have "borrowed" boolean variable > expect_SetActiveObject_active. Yes, it looks good. Thanks, Jacek

Aug. 14, 2005

Re: MSHMTL: Added QueryStatus implementation

by Saulius Krasuckas

* On Sun, 14 Aug 2005, Saulius Krasuckas wrote: > * On Sun, 14 Aug 2005, Jacek Caban wrote: > > > > Presently if you want to make this test not to crash, you may disable > > IOleCommand tests if UIActivate fails. Is something like this OK? I have "borrowed" boolean variable expect_SetActiveObject_active. | --- dlls/mshtml/tests/htmldoc.c 2005-08-14 19:33:22.000000000 +0300 | +++ /mnt/vcd2/wine/dlls/mshtml/tests/htmldoc.c 2005-08-14 19:22:26.000000000 +0300 | @@ -510,8 +510,8 @@ static HRESULT WINAPI DocumentSite_Activ | SET_EXPECT(OnUIActivate); | SET_EXPECT(SetActiveObject); | SET_EXPECT(ShowUI); | - expect_SetActiveObject_active = TRUE; | hres = IOleDocumentView_UIActivate(view, TRUE); | + expect_SetActiveObject_active = (hres == S_OK); | ok(hres == S_OK, "UIActivate failed: %08lx\n", hres); | CHECK_CALLED(CanInPlaceActivate); | CHECK_CALLED(GetWindowContext); | @@ -957,7 +957,7 @@ static void test_HTMLDocument(void) | CHECK_CALLED(ActivateMe); | } | | - if(cmdtrg) { | + if(cmdtrg && expect_SetActiveObject_active) { | int i; | | OLECMD cmd[2] = { | @@ -1020,7 +1020,7 @@ static void test_HTMLDocument(void) | CHECK_CALLED(OnUIDeactivate); | } | | - if(cmdtrg) | + if(cmdtrg && expect_SetActiveObject_active) | test_OleCommandTarget(cmdtrg); | | if(activeobject) { | @@ -1129,7 +1129,7 @@ static void test_HTMLDocument(void) | ok(tmp_hwnd == hwnd, "tmp_hwnd=%p, expected %p\n", tmp_hwnd, hwnd); | } | | - if(cmdtrg) | + if(cmdtrg && expect_SetActiveObject_active) | test_OleCommandTarget(cmdtrg); | | if(view) { > OLECMDID_OPEN seems to be supported at least on winME. I am curious, why? I mean OLECMDID_OPEN is *not supported* on winME. As isn't OLECMDID_NEW. Sorry for typo-inversions.

Aug. 14, 2005

Re: MSHMTL: Added QueryStatus implementation

by Saulius Krasuckas

* On Sun, 14 Aug 2005, Jacek Caban wrote: > > I'm not sure if it is a correct fix. Although it avoids crashes, > much less functionality of QueryStatus is tested. Before > your patch all possible commands were tested. This is true only for nt family windows. :-P On 9x test function exits on an exception. > it seems to be a case similar to crashes on xp while HTMLDocument is not > active in place. In this case it is not active in place because > UIActivate fails. Looking at the test results, UIActivate is a problem > on every win 9x and causes most tests to fail. So first UIActivate > should be fixed and then, if this problem remains, we'll be sure that > your fix is correct. I don't understand much in all this OLE/In-Place stuph, so I agree, but still I doubt this would be a sufficient to proof my patch is correct. :-] > Presently if you want to make this test not to crash, you may disable > IOleCommand tests if UIActivate fails. I will try, but what should be done with this (inside test_HTMLDocument)? | OLECMD cmd[2] = { | {OLECMDID_OPEN, 0xf0f0}, | {OLECMDID_GETPRINTTEMPLATE+1, 0xf0f0} | }; | | hres = IOleCommandTarget_QueryStatus(cmdtrg, NULL, 2, cmd, NULL); | ok(hres == OLECMDERR_E_NOTSUPPORTED, | "QueryStatus failed: %08lx, expected OLECMDERR_E_NOTSUPPORTED\n", hres); Or IOW, why first call generates exception on OLECMDID_OPEN command while second do not? | hres = IOleCommandTarget_QueryStatus(cmdtrg, NULL, 2, cmd, NULL); | hres = IOleCommandTarget_QueryStatus(cmdtrg, &IID_IHTMLDocument2, 2, cmd, NULL); OLECMDID_OPEN seems to be supported at least on winME. I am curious, why? > My guess is that it requires to be loaded before a call to UIActivate, What do you exactly mean by "it"? > so the attached patch might help (even if so, a few other tests will > fail, but currently the most interesting is UIActivate), No, the patch didn't help.

Aug. 14, 2005

Re: Regression in DVD Shrink

by Jonathan Ernst

Some more informations. Wine version: 20050725 The problem seems to be related with css encrypted discs. Scenarios: A: 1)put an unencrypted disc and mount it 2)run dvd shrink and open the disc => success B: 1)put a css encrypted disc and mount it 2)run dvd shrink and open the disc => failure C: 1)put a css encrypted disc and mount it 2)run dvdbackup and let it find the keys using libdvdcss 3)run dvd shrink and open the disc => success D: 1)put a css encrypted disc and mount it 2)run dvd shrink and open the disc (failure) 3)run dvdbackup and let it find the keys using libdvdcss => failure (i.e. dvdbackup fails until I umount and remount the disc) Using Wine 20050628 the same problems arise. Before everything was working from the start but I think that before gnome was opening my dvd using a media player when automounting so that the decryption process might already have taken place before I run DVD Shrink. I'm changing the title of this bug report to reflect this. WINEDEBUG=+aspi doesn't give more informations. Le vendredi 12 août 2005 à 15:44 -0600, Vitaliy Margolen a écrit : > Friday, August 12, 2005, 4:13:12 AM, Jonathan Ernst wrote: > > > Since latest Wine release DVD Shrink cannot open a DVD anymore. > Do you referring to CVS or version 20050725? > > Could you add +aspi trace log to your bug report? > > Vitaliy > > > -- Jonathan Ernst <Jonathan(a)ErnstFamily.ch>

Aug. 14, 2005

Re: RichEdit flicker

by Phil Krylov

On Sat, 13 Aug 2005 18:51:06 +0400 Phil Krylov <phil(a)newstar.rinet.ru> wrote: > > The paragraph structure should include not MEPF_REWRAP and MEPF_REPAINT > > flags, but indexes of rows from which to start re-wrapping and repainting > > (e.g. nStartRewrap and nStartRepaint). The wrapping routine should check if > > it has actually changed wrapping and set nStartRepaint accordingly. > > > > ME_Repaint should not call ME_PaintContent directly. Instead, the wrapping > > routine (and probably others) should call InvalidateRect for screen areas > > that need to be repainted. > > On other hand, the current code is pretty stable although flickering. > Probably flickering could be more easily by drawing to an offscreen bitmap > which would be just exposed by WM_PAINT. I've just sent a patch that implements both approaches to wine-patches. -- Ph.

Aug. 14, 2005