March 2003 - Wine-devel - list.winehq.org

Re: revised direct sound capture patches
by Eric Pouech 01 Mar '03

01 Mar '03

Robert Reif wrote: > This revised patch set addresses the comments I got on > the previous patch set. looks way better... and keep on the good work on the capture part (which hasn't been well covered so far) A+ -- Eric Pouech

1 0

Re: d3dx8_math interface and stubs
by Raphaël Junqueira 01 Mar '03

01 Mar '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Vendredi 28 Février 2003 17:31, Rok Mandeljc a écrit : > I've implemented part of d3dx8.dll related to d3dx8math.h header (stubs, > I'll implement real functs later). > This is my first work with COM interfaces so please someone check it if > it's ok. Great ;) For me it seems correct, but i can't test now as i am not at home Problems: - - your headers are too "microsoft compliant": i can't use copy&paste with microsft headers for wine headers ;( - - inlining headers are not very usable with most of the unix compilers so you have to find a way to get it working (in my proto, i haven't inlining actived) If you want to play wuth dx i have already done most of the easy implementations of maths functions, MatrixStack is almost complete, etc... The last time i worked for dx8, i was trying to get D3DXFont working ... But i haven"t send it because lack of time ;( Regards Raphael PS: sorry for my very poor english, but i had an operation at my left eye, and i can't see very well ;((( > ChangeLog: > - added files: > - wine/dlls/d3dx8/d3dx8math.c (direct3d x 8 math functions) > - wine/dlls/d3dx8/d3dx8math_private.h (ID3DXMatrixStack > Implementation) > - wine/dlls/d3dx8/d3dxmatrixstack.c (ID3DXMatrixStack stubs) > - wine/include/d3dx8math.h (Direct3D X 8 Math definitions and > ID3DXMatrixStack Interface) > - wine/include/d3dx8math.inl (inline Direct3D X 8 Math functions) > - some minor adjustments in existing files -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+YIpSp7NA3AmQTU4RAjwSAKCdHibb6O4gggcSTFIZycJTvdTcQACZAbdR dRh7Vk+kqgTW8fXDTUEFuwI= =czE5 -----END PGP SIGNATURE-----

1 0

Re: more direct sound capture fixes
by Robert Reif 01 Mar '03

01 Mar '03

Thanks for the feedback. I know the debugging code is getting out of hand but what is the recommended way of providing useable traces. Should the debug code be put in a separate file? Are there standard routines for converting constants to readable strings? I'm new to wine so I don't know what the current practices are yet. The critical section was put in there because there is the potential of accessing that variable from all three threads. It's overkill now and probably not needed but I'm trying to track down some weird behavior in full duplex mode. That variable stores the state of both the read and write threads so we need to do bit opps on it. The current behavior of the driver reorders commands by placing ones that must be waited on at the head of the queue. Not sure why but I added that #define to allow it to be disabled. It makes the capture code more stable and deterministic. It defaults to the current behavior. I was running into under run problems in the capture thread where it had data to save but no headers to put it in. The headers were in the queue but ignored until after the timeout period. I added code to peek into the queue rather than giving up and it fixed the under run problem. I'm also having problems with the mixer and primary buffers and am trying to figure them out but I suspect a similar problem. The OSS people don't recommend using multiple threads for reading and writing. Three are currently used: the main app thread where the sound device is opened, one for writing and one for reading. Could this have something to do with my full duplex problems? audio.c is getting big with both input and output and wave and direct sound all together. Do we want to break it up someday? What about hardware mixing? Is anyone working on redesigning this? My needs are short term. I need to get my app working under wine right now but I would like to see direct sound audio better integrated someday and am willing to help. Thanks, Bob. Eric Pouech wrote: > > wineoss.diff: > > Added more debugging code. > it really starts being ugly and inefficient > > Started work on direct sound capture driver. > > Tried to get wave driver to work better in full duplex mode. > > Capture works but playback has problems. > just a few questions: > - I don't think you need the enable_crst, do you ? I don't think the > ioctl will be done in parallel anyway > - why do you need to change the message order ? you'd better in wave > capture, when you run out of waveheaders try to process the pending > messages (as we do in wave playback) before sending back an error, > without reordering them > > A+ > > -- > Eric Pouech

2 1

wcmd aliases
by J. Grant 01 Mar '03

01 Mar '03

Hello, A couple of aliases in wcmd would make life much simpler, common commands all have unix style alternatives such as dir -> ls, copy -> cp etc, could these be added as aliases of the DOS commands please? in the same way that dir works in the bash shell because it is aliased to ls. Regards JG

2 1

Wine dir
by J. Grant 01 Mar '03

01 Mar '03

Hello, After reading through my "config" file I pondered why the default Wine installation dir was c:\windows, in MS-Windows 9x,ntxx etc the instalation dir can be anything, "windows" and "winnt" being common defaults, as well as "win2k" I saw on some custom install machines. There is an enviroment variable and "config", "Windows" setting in the [wine] block and perhaps a registry setting for this. Would it be more appropriate to use "wine" as the instalation dir? e.g. "c:\wine" Regards JG

1 0