Re: Various problems- it just gets worse!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

when installing the next time: just run wineinstall. It *really* makes
things easier. :-)

To fix this sound problem: You could try using another sound-driver in your
~/.wine/config to see if that works better. Maybe try the ALSA one, or the
OSS..

Good luck,
Philipp

----- Original Message -----
From: "Tom Barnes-Lawrence" <tomble@usermail.com>
To: <wine-users@winehq.com>
Sent: Sunday, June 29, 2003 4:36 AM
Subject: Re: Various problems- it just gets worse!


> On Sun, Jun 29, 2003 at 01:49:57AM +0100, Tom Barnes-Lawrence wrote:
> > On Sat, Jun 28, 2003 at 05:14:56PM -0700, Duane Clark wrote:
> >
> > > If you want to be sure, read the file winedefault.reg, and compare it
to
> > > ~/.wine/system.reg. The format is slightly different, but the
> > > differences should be obvious.
> >
> >   That's the thing! There *is* not system.reg, not in ~/.wine, not in
> > the windows directory I made, not anywhere. That was why I was getting
> > so frustrated- there was no sign of regedit having created or altered
> > ANY file whatsoever. The document about the registry talks about lots
> > of different files foo.reg and bar.dat and whatever. Doesn't say what
> > regedit is supposed to actually create or modify though.
> >
> > > Regedit probably did work (I see no reason to think otherwise).
> >
> >  As there is not system.reg, or anythingelse.reg anywhere, I'd say it
> > probably didn't.
> >
>  Right, since getting that bit of information (eg- that wine expects to
> find its registry files in the ~/.wine directory, not the actual windows
> directory), I managed to eventually create what seems to be a valid
> registry file. AFAICT, I had to do
>
>  regedit /e windefault.reg,
>
> and then the newly created registry file overwrote windefault.reg-
> I noticed the file had grown, and then saw the contents seemed different.
> So I then had to rename it to system.reg, and THEN winecheck was happy.
>
>  Still didn't improve the sound, or the keys, etc.
>  But I eventually noticed that there was a stale "wineserver" process
> still running (with instances of "dxhelp" running under it). I realised
> this might have made a difference, so I killed all those.
>
>  Restarted Total Annihilation- the mouse was grabbed, and the keyboard
> worked fine! So it seems that the changes I'd tried to make to the
> config file hadn't been making a difference because the old wineserver
> didn't reread it, and wine was connecting to that instead.
>
>  I'd be suprised if many newbies could work that out. It took me most of
> the day. I'm not saying wine should change the way it works there, but
> that bit of advice should be made clearer IMO.
>
>  So: I've now only got the issue of the in-game sound to figure out
> (as I said, it works fine in the FMV, although it does start with a
> bit of annoying noise). At least the game is now playable.
>
>  Using -debugmsg warn+dsound   gave a few messages like:
>
> warn:dsound:DSOUND_CalcPlayPosition detected an underrun: primary queue
was
> 63680
>
> when I clicked the menu buttons (which *should* make a noise), but no
> messages seemed to be given when I clicked the "test sounds" button...
> Perhaps that goes through a different library or something. Any ideas?
>
> Tom Barnes-Lawrence
> _______________________________________________
> wine-users mailing list
> wine-users@winehq.com
> http://www.winehq.com/mailman/listinfo/wine-users
>

_______________________________________________
wine-users mailing list
wine-users@winehq.com
http://www.winehq.com/mailman/listinfo/wine-users

[Index of Archives]     [Gimp for Windows]     [Red Hat]     [Samba]     [Yosemite Camping]     [Graphics Cards]     [Wine Home]

  Powered by Linux