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

dsound buffer underrun

by Tomas Carnecky

I'm still having problems with the sound, something in the dsound mixer is wrong. I've created a trace (+dsound): first comes this, that shows that sdound detected a possible underrun and sets probably_valid_to to -1. trace:dsound:DSOUND_MixOne (0x55952b88,54684,54684,49392) trace:dsound:DSOUND_MixOne buf_writepos=8192, primary_writepos=54684 trace:dsound:DSOUND_MixOne buf_done=0, primary_done=0 trace:dsound:DSOUND_MixOne buf_mixpos=8192, primary_mixpos=54684, mixlen=49392 trace:dsound:DSOUND_MixOne looping=1, startpos=0, leadin=0 trace:dsound:DSOUND_MixOne streaming buffer probably_valid_to=8192, probably_valid_left=0 warn:dsound:DSOUND_MixOne probably_valid_to now within writelead, possible streaming underrun trace:dsound:DSOUND_MixOne remaining mixlen=49392 next time wine enters DSOUND_MixOne() this occurs: trace:dsound:DSOUND_MixOne (0x55952b88,54684,63504,49392) trace:dsound:DSOUND_MixOne buf_writepos=17012, primary_writepos=63504 trace:dsound:DSOUND_MixOne buf_done=7804, primary_done=40572 trace:dsound:DSOUND_MixOne buf_mixpos=24816, primary_mixpos=19404, mixlen=49392 trace:dsound:DSOUND_MixOne looping=1, startpos=0, leadin=0 trace:dsound:DSOUND_MixOne streaming buffer probably_valid_to=-1, probably_valid_left=32768 trace:dsound:DSOUND_MixOne clipping to probably_valid_left=32768 fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=32768 < primary_done=40572) now wine clips mixlen to probably_valid_left which is smaller than primary_done. I don't know what primary_done, mixlen, probably_valid_left and probably_valid_to mean, but somthing with those variables is wrong. the full log is in the attachment tom

Dec. 5, 2005

Re: Why Steam fails

by Scott Ritchie

On Mon, 2005-12-05 at 00:41 -0800, James Liggett wrote: > On Mon, 2005-12-05 at 03:24 -0500, Ivan Gyurdiev wrote: > > I think hardware problems with the RAM are highly unlikely. I've had > > plenty of those, and when your RAM is defective, nothing works - you get > > spurious kernel panics, and you will find out that it's defective > > really soon. > Well, that might be true most of the time, but not always. Case in > point: a while back I was helping a friend of my brother's build a > computer. We loaded Windows XP and a couple games on it (Half-Life, Max > Payne, a few others which I can't remember) Things seemed to work fine. > Then we tested the games. Everything except HL hard-locked the machine. > It drove us nuts all night trying to figure it out. The next day the guy > swapped out his ram (for reasons I can't explain) and things worked > fine. It just goes to show that sometimes it can be what you least > expect... ;-) I wish I could shed a little more light on your plight > though. I wish you the best of luck :) > > James Just run memtest86 on the machine overnight. That'll tell you whether there's a hardware memory issue or not. -Scott Ritchie

Dec. 5, 2005

Re: ddraw: make some driver info not const

by Alexandre Julliard

Rein Klazes <wijn(a)wanadoo.nl> writes: > + __TRY > + { > if (!lpCallback((DDRAW_default_driver == i) ? NULL > :(LPGUID)&DDRAW_drivers[i]->info->guidDeviceIdentifier, > (LPSTR)DDRAW_drivers[i]->info->szDescription, > (LPSTR)DDRAW_drivers[i]->info->szDriver, > lpContext, 0)) > return DD_OK; You can't return from inside a __TRY block. -- Alexandre Julliard julliard(a)winehq.org

Dec. 5, 2005

Re: trouble with uxtheme dll

by Alexandre Julliard

Stefan Leichter <Stefan.Leichter(a)camLine.com> writes: > As i understand you, the ordinals of uxtheme dll displayed in the relay trace > are wrong. Different function calls (according to the number of arguments) in > the relay log are displayed as function with the ordianl 1. Most likely we failed to find the right module, and uxtheme happens to be the last in the module list. Try adding some debug in get_entry_point() in dlls/ntdll/relay.c to figure out what's going on. -- Alexandre Julliard julliard(a)winehq.org

Dec. 5, 2005

Re: Allow out-of-tree builds against configured source tree

by Alexandre Julliard

Pavel Roskin <proski(a)gnu.org> writes: > * Make.rules.in: Change include path to prefer include files in > the output tree over those in the source tree. This allows > compiling Wine outside the source tree even if Wine was already > compiled in the source tree, possibly with different options. You really don't want to do that, that's a recipe for trouble. Make will check the source dir for dependencies so if you have objects in there it won't rebuild things properly. -- Alexandre Julliard julliard(a)winehq.org

Dec. 5, 2005

Re: wglGetPixelFormatAttribivARB unexpected RenderType(100)

by Raphael

On Monday 05 December 2005 04:41, Toan T Nguyen wrote: > Here they are. > > On 12/4/05, Raphael <fenix(a)club-internet.fr> wrote: > > On Saturday 03 December 2005 09:20, Toan T Nguyen wrote: > > > FYI, here is the code in question: > > > > > > http://cvs.sourceforge.net/viewcvs.py/q2e/q2e/source/win32/glw_win.c?re > > >v=1. 13&view=auto > > > > > > The function where pixelFormat is initialized is GLW_ChoosePixelFormat. > > > > > > Toan > > > > Hi, > > > > behavior seems strange to me > > > > can you provide me output of gxlinfo > > and output of (using patch) > > WINEDEBUG="+opengl" q2.... > > > > Thx > > > > Regards, > > Raphael Thx Can you retry with this patch ? Thx Regards, Raphael

Dec. 5, 2005

Re: Why Steam fails [VirtualAlloc]

by Mike Hearn

On Sat, 03 Dec 2005 20:39:01 -0600, Rob Shearman wrote: > I would suggest playing around with the prelink tool to put > dynamic libraries in better positions in memory. Another thing to try is disabling execshield and VMA randomization: echo 0 >/proc/sys/kernel/exec-shield echo 0 >/proc/sys/kernel/randomize_va_space thanks -mike

Dec. 5, 2005

Re: Why Steam fails [VirtualAlloc]

by Ivan Gyurdiev

>>> ...which doesn't happen in your test program as it doesn't use as >>> many. Remember that it takes only one page of memory sitting at the >>> wrong virtual memory address to divide the available contiguous >>> addresses in half. I would suggest playing around with the prelink >>> tool to put dynamic libraries in better positions in memory. >>> >> I can take a look, but this is a Fedora Rawhide machine, which should >> run prelink nightly. >> > > I found our mmap - reserve area handling to be problematic for > low memory machines... > > You can try disabling it (just check libs/wine/mmap.c, mmap_init() > and change the first #if to #if 0.) > Thanks for the suggestion, but it doesn't help. I don't think this is a low-memory machine - it has plenty of memory (1G + 512 swap), and most if it is unused. The gnome resource monitor shows 30-40% usage, and it doesn't spike at all when steam is used. I see some libraries didn't prelink in the log, so I'll try Rob's suggestion, and see if prelink helps things. I am not optimistic though - I've seen this problem for a long time...

Dec. 5, 2005

Re: [MSI] DllCanUnloadNow try2

by Christian Gmeiner

Dmitry Timoshkov wrote: >"Christian Gmeiner" <christian.gmeiner(a)students.fh-vorarlberg.ac.at> wrote: > > > >>+/********************************************************************** >>+ * Dll lifetime tracking declaration >>+ */ >>+void LockModule(void) >>+{ >>+ InterlockedIncrement(&dll_count); >>+} >>+ >>+void UnlockModule(void) >>+{ >>+ InterlockedDecrement(&dll_count); >>+} >> >> > >Since these 2 are used from inside single source file they can (and should) be >made static. > > > Thanks for your hint. Try 3 of my patch should be ok now - i hope. Greets, Christian -- Christian Gmeiner - student of computer science http://dxr3plugin.sf.net http://itb04.ath.cx

Dec. 5, 2005

Re: DirectDraw over Direct3D

by Roderick Colenbrander

> This patch seems similar to glSDL where it wraps SDL's 2d API to > OpenGL. The good thing about this it can provide acceleration and not > require root like DGA. The bad thing with this idea is that it can't > be used on older video cards or even some newer ones that lack proper > direct rendering. Am I correct that even when just doing depth > conversions, without direct rendering it will still be slow? > Perhaps I should clarify some misunderstandings that some people have. (I hope I explain it correctly) Basicly DirectDraw provides a mechanism to directly access the framebuffer of the videocard. This is the fastest way to render 2D images on the screen. Games like StarCraft, Total Annihilation, C&C and lots of others use DirectDraw in this way. Second there's another class of games like Age Of Empires2, Heroes of Might and Magic IV and others which mix ddraw with GDI. They for instance render a image using ddraw and then use GetDC/ReleaseDC to get a device context so that they can draw in the surface. (directly into the video memory) In case of X direct framebuffer access is only possible through DGA but it is unsecure and has other issues. When DGA works correctly it can accelerate games like StarCraft. Further DGA doesn't have any depth conversion issues as it does depth switching. Without DGA the rendering operations need to go through X. Because of limitations of X, depth conversion problems appear when the depth of the desktop and X aren't the same. For depth conversion purposes Wine's DirectDraw uses a DIB section. Basicly all pixels of an image are translated to the depth of X. This is slow and especially for the case when the application requests 8bit paletted mode using a 24bit desktop. In this case a color lookup needs to happen in a palette for each pixel. The end result is then shown on the screen (if the game is of the StarCraft type) Games that use GetDC/ReleaseDC can't work using DGA. The performance in general isn't great as lots of X calls happen. (things like conversions from XPixmap to XImages and the way around and also depth conversions happen a lot) The patch I sent works for both classes of games though it won't help much for the second class as GetDC/ReleaseDC stuff is slow. As explained before the patch uploads the surface to a texture which is then rendered using OpenGL. This is quite fast and as a bonus the videocard can do all depth conversion for us as it isn't limited to rendering textures which are at the same depth as X. For old videocards the GL renderer won't work and the old code should work fine (except for performance issues). You might have heard people talking about a 'dibengine' which would let Wine do all DIB related operations in software which would save a lot of XImage/XPixmap conversions. (conversion is only needed for the final rendering stage) This dibengine would mainly accelerate games that use GetDC/ReleaseDC. It won't help games like StarCraft (much) as for those DIBs were only used for depth conversion and the conversion algorithm stays the same (it can't be tweaked much if at all). So there's not really a way to speedup games like StarCraft for old videocards. Perhaps XShm might be of use but not sure how much it would help. (think it would only be usefull for GetDC/ReleaseDC games) Roderick -- Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie -- Highspeed-Freiheit. Bei GMX superg�nstig, z.B. GMX DSL_Cityflat, DSL-Flatrate f�r nur 4,99 Euro/Monat* http://www.gmx.net/de/go/dsl

Dec. 5, 2005