Re: audio.c converted from WaitForSingleObject to poll
--- eric pouech [EMAIL PROTECTED] wrote: well, from a pure semantic point of view, I think we have to wait. I've shown (to myself) experimentally that just removing the waits breaks. What I've done instead is reversed my poll patch and added a patch to mmsystem.c which causes application (and possibly some non-application) callbacks to be called from a different thread so that wodPlayer_Notify doesn't ever halt waiting for the application to return (which may in turn be waiting on wodReset,wodRestart, wodClose, wodPause etc). I'll post this to wine-patches in just a moment. for wodGetPosition, it currently returns the position of data which have been notified to the app (and which has been actually played). What's the exact issue on HL ? With the audio.c poll patch I posted, wodPlayer_Notify doesn't update the total bytes played until after sufficient time has elapsed for the dsp to have finished playing it. The absence of more data to send to the dsp may stop the polling loop before all sounds have been played, meaning that the total bytes for a the last sample written may not be updated until the next wave is queued to be written to the dsp. It appears that HL loops checking wodGetPosition until the last sound has been played before writing the next sound. This never happens with my poll patch because of the issue in the previous para. Hence: no sound. I verified this by doing another evil hack which just notified and updated total bytes as soon as they were written. The sound returned. __ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com
Re: config.h reorg part 2: config.h includes
François Gouget wrote: [...] Changelog: François Gouget [EMAIL PROTECTED] * console/xterm.c, [...] windows/x11drv/clipboard.c Fix the #include order for config.h Add #include config.h directives where needed Fixes the FILE_OFFSET_BITS redefinition warnings on Solaris (part 2) There was a #include config.h missing in dlls/ddraw/mesa.c in the above patch. The attached patch fixes that. It complements part 2 (p20011031-config.diff) and must thus be applied before part 3 (p20011031-config2.diff) -- François Gouget [EMAIL PROTECTED] Index: dlls/ddraw/mesa.c === RCS file: /home/wine/wine/dlls/ddraw/mesa.c,v retrieving revision 1.3 diff -u -r1.3 mesa.c --- dlls/ddraw/mesa.c 2000/11/27 23:54:26 1.3 +++ dlls/ddraw/mesa.c 2001/11/01 07:51:07 @@ -3,6 +3,8 @@ This file contains all MESA common code */ +#include config.h + #include windef.h #include wine/obj_base.h #include ddraw.h
mmsystem.c callback thread patch.
The patch I wrote for mmsystem.c doesn't fix my problem with HomeWorld, so back to the drawing board on that one. The patch fixes a problem that I've only ever seen in HalfLife while I was messing with the innards of wodPlayer and assumes that wodPlayer_Notify can trigger a callback into the application. If that assumption is invalid, please ignore the patch and let me know so I can look into it further. Note that this also changes the semantics of the callbacks because wodPlayer is not halted waiting for the callback to complete, __ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com
Re: audio.c converted from WaitForSingleObject to poll
What I've done instead is reversed my poll patch and
added a patch to mmsystem.c which causes application
(and possibly some non-application) callbacks to be
called from a different thread so that
wodPlayer_Notify doesn't ever halt waiting for the
application to return (which may in turn be waiting on
wodReset,wodRestart, wodClose, wodPause etc). I'll
post this to wine-patches in just a moment.
well, I think it's a bit overkill. furthermore, this won't
let synchronize that the notification has been done before
returning from the call. this stops waiting in notify, but
doesn't synchronize at the end (except if you wrap every
entry point in winmm/mmsys which might generate a
notification with a synchro with this extra thread)
I think we should not use a general event for the synchro
in audio.c, but rather create a new event for each time we
need to wait (wodReset...) and pass it to the WWO_MSG struct,
hence removing the race condition. does the attached patch
solves your issue ?
With the audio.c poll patch I posted, wodPlayer_Notify
doesn't update the total bytes played until after
sufficient time has elapsed for the dsp to have
finished playing it. The absence of more data to send
to the dsp may stop the polling loop before all sounds
have been played, meaning that the total bytes for a
the last sample written may not be updated until the
next wave is queued to be written to the dsp.
It appears that HL loops checking wodGetPosition until
the last sound has been played before writing the next
sound. This never happens with my poll patch because
of the issue in the previous para. Hence: no sound.
I verified this by doing another evil hack which just
notified and updated total bytes as soon as they were
written. The sound returned.
ok (I didn't get it was with the poll patch applied)
but OTOH, the poll patch can have nasty effects:
1/ let's assume an app uses only two wavehdr:s which cumuled
size if smaller than the OSS play ring
2/ the app will send the two wavehdr:s and they will be queued
and written to /dev/dsp
3/ if we use the modification to not have the busy wait, then
no notification will be ever made (IIRC some Flash apps are
doing this). They normally wait for notification to occur
in order to resubmit the same wavehdr:s will different
values
so, I think the poll patch (even with some modifications)
introduces some more evil parts than it fixes (and your deadlock
issues don't come from the playback loop)
A+
--
---
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
The future will be better tomorrow, Vice President Dan Quayle
Index: dlls/winmm/wineoss/audio.c
===
RCS file: /usr/share/cvs/cvsroot/wine/wine/dlls/winmm/wineoss/audio.c,v
retrieving revision 1.44
diff -u -r1.44 audio.c
--- dlls/winmm/wineoss/audio.c 2001/08/18 16:09:41 1.44
+++ dlls/winmm/wineoss/audio.c 2001/11/01 10:19:52
@@ -87,6 +87,7 @@
typedef struct {
int msg;
DWORD param;
+HANDLE hEvent;
} WWO_MSG;
typedef struct {
@@ -109,9 +110,9 @@
DWORD dwRemain; /* number of bytes to write to
end the current fragment */
/* synchronization stuff */
+HANDLE hStartUpEvent;
HANDLE hThread;
DWORD dwThreadID;
-HANDLE hEvent;
#define WWO_RING_BUFFER_SIZE 30
WWO_MSGmessages[WWO_RING_BUFFER_SIZE];
intmsg_tosave;
@@ -522,29 +523,40 @@
}
-int wodPlayer_Message(WINE_WAVEOUT *wwo, int msg, DWORD param)
+static int wodPlayer_Message(WINE_WAVEOUT *wwo, int msg, DWORD param, BOOL wait)
{
+HANDLE hEvent;
+
EnterCriticalSection(wwo-msg_crst);
if ((wwo-msg_tosave == wwo-msg_toget) /* buffer overflow ? */
- (wwo-messages[wwo-msg_toget].msg))
+(wwo-messages[wwo-msg_toget].msg))
{
ERR(buffer overflow !?\n);
LeaveCriticalSection(wwo-msg_crst);
return 0;
}
+hEvent = wait ? CreateEventA(NULL, FALSE, FALSE, NULL) : INVALID_HANDLE_VALUE;
+
wwo-messages[wwo-msg_tosave].msg = msg;
wwo-messages[wwo-msg_tosave].param = param;
+wwo-messages[wwo-msg_tosave].hEvent = hEvent;
+
wwo-msg_tosave++;
if (wwo-msg_tosave WWO_RING_BUFFER_SIZE-1)
wwo-msg_tosave = 0;
LeaveCriticalSection(wwo-msg_crst);
/* signal a new message */
SetEvent(wwo-msg_event);
+if (wait)
+{
+ WaitForSingleObject(hEvent, INFINITE);
+ CloseHandle(hEvent);
+}
return 1;
}
-int wodPlayer_RetrieveMessage(WINE_WAVEOUT *wwo, int *msg, DWORD *param)
+static int wodPlayer_RetrieveMessage(WINE_WAVEOUT *wwo, int *msg, DWORD *param,
+HANDLE *hEvent)
{
EnterCriticalSection(wwo-msg_crst);
@@ -557,6 +569,7 @@
*msg = wwo-messages[wwo-msg_toget].msg;
Re: LockFile - any words of warning?
Thanks Rein Klazes [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... On Wed, 31 Oct 2001 10:37:11 -0800, you wrote: Have a look at Corel's wine tree, where it is implemented. Please excuse my ignorance; how do I get at the Corel tree? Hmm, the instructions seem to have been moved off Corel's site and not reappeared at Xandra's yet. BTW what is Xandra all about? (e.g. what url?)
Re: change cdrom?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi again! I found a solution: I'm lucky enough to have 2 cdroms... 1 dvd and 1 cdrw. The solution was to put cd2 in the other drive and mount it OVER the first mount. Not a very pretty solution but it worked. Do you guys know of a better solution? Personally I think that wine d:setup.exe would be better.. Regards Per Wigren BTW, sorry for posting this on the devel-list instead of user. I've lost my mailaccount that was subscribed to wine-users. Thursday 01 November 2001 18.24 skrev du: Hi! I have an annoying problem installing Grim Fandango. It comes on 2 cds. If I mount the cd and run wine setup.exe it starts to install until it asks for cd #2. But I can't unmount the CD to put in cd2 because it's busy... If I run eject, it ejects but it still seems to be cached so it doesn't recognize that I've changed cd! Also: # wine D:\\setup.exe with the cdrom unmounted doesn't work either... :( Any solution to this problem? Regards Per Wigren -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE74Y//yjnjcyLO8HkRAiOoAJ9DFa739Gcbo7lqrczSVlROSQJk9wCfS3BM votIGfjMtJIk4akHfd6BrXI= =weMU -END PGP SIGNATURE-
Re: change cdrom?
mount. Not a very pretty solution but it worked. Do you guys know of a better solution? some fixes are floating around. try latest cvs, it may be fully fixed A+ -- --- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle
Re: LockFile - any words of warning?
On Thu, 1 Nov 2001 07:45:46 -0800, you wrote: Thanks Rein Klazes [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... On Wed, 31 Oct 2001 10:37:11 -0800, you wrote: Have a look at Corel's wine tree, where it is implemented. Please excuse my ignorance; how do I get at the Corel tree? Hmm, the instructions seem to have been moved off Corel's site and not reappeared at Xandra's yet. BTW what is Xandra all about? (e.g. what url?) Sorry it is Xandros, it seems they bought corel's linux business. I was forwarded to their site when I tried to locate the page where the instructions downloading corelwine used to be: http://linux.corel.com/opensource/ The original page is btw, still at http://opensource.corel.com Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: Duplicated StrRetToStr functions in shell32
Francois,
The reason that these routines were duplicated is that the builtin shell32
cannot find StrRetToBuf{A|W} in some of the native versions of shlwapi.dll.
This dependency prohibited testing with builtin vs. native shlwapi.
The change was submitted to winehq about 8/28 and committed soon thereafter.
Guy
- Original Message -
From: Francois Gouget [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, October 31, 2001 11:46 PM
Subject: Duplicated StrRetToStr functions in shell32
Shell32 contains StrRetToStrNA and StrRetToStrNW which are almost
identical to StrRetToBufA and StrRetToBufW. Since shell32 already
imports shlwapi it seems like we should just call the latter functions!
That way I won't have to fix the 0x%p thing twice.
Changelog:
* dlls/shell32/shellstring.c
Implement StrRetToStrN{A,W} by calling shlwapi.StrRetToBuf{A,W}
instead of duplicating the code
--
Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/
I haven't lost my mind, it's backed up on tape around here
somewhere...
Re: Duplicated StrRetToStr functions in shell32
On Thu, 1 Nov 2001, Guy L. Albertelli wrote:
Francois,
The reason that these routines were duplicated is that the builtin shell32
cannot find StrRetToBuf{A|W} in some of the native versions of shlwapi.dll.
This dependency prohibited testing with builtin vs. native shlwapi.
The change was submitted to winehq about 8/28 and committed soon thereafter.
Aaaah. Ok.
Then I suggest that we add a comment in the source that says so, in
both the shell32 and shlwapi implementations. This way when one
implementation is updated the others acutally have a chance of being
updated too.
--
Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/
Utilisateur (nom commun) :
Mot utilisé par les informaticiens en lieu et place d'idiot.
Yet again: audio.c stuff
I've posted a substantial patch to audio.c which reorganises the code to make it a little easier to follow. It's been tested against HomeWorld and HalfLife. It works against homeworld with MIN_SLEEP_TIME 100, but not with MIN_SLEEP_TIME =50. Feel free to set MIN_SLEEP_TIME to 0 to remove the minimum sleep time. The other thing the patch does is makes notifications dependant on bytes played rather than time elapsed. Should be a win overall. I'm still having no luck with tracking the actual race condition which causes HomeWorld to fail. I've not tried the patch you sent to fix the callback notification problem yet. I'll let you know when I do. __ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com
