I downloaded and ran the QuickTime installer and the
Pajama Sam demo last PM.
I have reproduced the problem with Pajama Sam (it
seems that ends of samples are either not playing or
being overwritten), but I can't get
QuickTimePlayer.exe to do anything at all.
I'll investigate the Pajama Sam
The problem is that I advance to the next wavehdr
automatically in FeedDSP, which skips the first
wavehdr sent to the wodPlayer. Doh! A patch will
follow to fix this (which will be built on top of the
race condition fix patch).
__
Do You Yahoo!?
--- Ori Pessach [EMAIL PROTECTED] wrote:
Again, this used to work before. I first tried it
with Simon's recent patch,
and then checked out current the CVS version of
mmsystem.c, and I don't see a
difference.
I've looked at the patches I've posted. My audio.c
readability patch has been
I've posted my patch against wine cvs audio.c 1.44 to
wine patches, but I've not yet been able to give it a
thorough test.
Anyone using freeware/shareware/opensource programs
with sound under wine (not winex) please send me URLs
for the programs you use (specially if they break) so
I can use
--- 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
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
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
--- Eric Pouech [EMAIL PROTECTED] wrote:
you just need to make a windows handle from the unix
fd (the one of /dev/dsp) and do a
WaitOnMultipleObjects with 2 handles :
- the /dev/dsp handle
- the synchronization mechanism with all the wodXXX
functions.
Didn't know I could do that. I do now
Please forgive the length of this missive, I have not
the time to write a short one.
There are a couple of (serious) bugs in my patch to do
with notifications (more latere). It has, however,
uncovered a couple of race conditions that
applications may trigger to hang the wodPlayer with or
--- Eric Pouech [EMAIL PROTECTED] wrote:
well, from a generic point of view this is something
to be done
however, I don't see where you'd like to dispatch
the event to ?
the playback thread in this case would have to wait
on two different things:
- the /dev/dsp fd (when the queue becomes
--- Francois Gouget [EMAIL PROTECTED] wrote:
Making Wine suid? No way!
And I don't have an SMP computer either (plus
that was on my laptop).
There has to be something else.
I see that there's a ptrace change in the changelog
for Linux 2.4.7 having to do with /proc and core dump
--- eric pouech [EMAIL PROTECTED] wrote:
there may also some issues on SMP machines ? are you
both lucky SMP boxes users ?
No SMP here.
__
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com
I've attacked homeworld for a couple of hours with IDA
free and none of the places that set the value of the
NULL pointer are remotely close to a waveOutWrite
call.
I've run -debugmsg +wave with and without the
synchronous wodWrite patch. The results are fairly
large so I won't send them
Having reviewed the changelog for Linux 2.4.7, I find
that the ptrace attach code was amalgamated from many
architecture dependant files into one function :
ptrace_attach. This function differs from previous
functions on i386 in that it returns EPERM if:
1) task-mm is NULL
2) task-pid = 1
3)
--- eric pouech [EMAIL PROTECTED] wrote:
after, rereading my old code, there's nothing wrong
(at first glance) here some invocations (like close,
reset) need to be synchronous
(the calling thread blocks until the rendering
thread is done with the message), some others (like
adding a
--- eric pouech [EMAIL PROTECTED] wrote:
ok, so making the wavehdr playback synchronous
seems to trigger this bug...
It seems that way. I'll investigate further this PM.
some prior point in the execution. Any tips for
rapid location of where it's being stored?
1/ use a bt in winedbg
16 matches
Mail list logo
