#1 doesn't work at all, is that right? Or does it work with hardware
accel sound?
Sound is OK when doing hardware acceleration but the game
is unplayable because it's running way slower than real time because
the loader and server are using 90+% of the CPU.
Hmm. This is very interesting; I may
Jeremy White wrote:
Could you recap this for me? Afaik, we have 4 cases:
1) Current CVS tip
2) With a hack to kill the yield in wait timeouts
3) With my experimental priority adjustor
4) Behavior last fall before I started messing around.
So, #4 worked well with NFS3, in both modes?
c
>
> Unfortunately, Myst appears to only work under Wine
> with rather old
> kernels. It works fine for me on RH7.3, kernel
> 2.4.18, as long as I back
> out that mmtime patch. But Myst fails to work on
> RH9, kernel 2.4.20, for
> reasons unrelated to the mmtime patch. However, it
> fails after
Jeremy White wrote:
I'll just mention that, assuming you are referring to this patch:
http://cvs.winehq.org/patch.py?id=14198
it also causes a regression in Myst. Though I am not convinced the fault
is in the patch, rather than the patch exposing some other problem.
Would you mind trying my exper
Robert Reif wrote:
Jeremy White wrote:
Could you try the attached experimental patch and see
if it eliminates the NFS3 problem?
It fixes the problem in NFS3 when using hardware
accelerated sound. Sound is really messed up when
using HardwareAcceleration = Emulation.
The direct sound regression tes
I'll just mention that, assuming you are referring to this patch:
http://cvs.winehq.org/patch.py?id=14198
it also causes a regression in Myst. Though I am not convinced the fault
is in the patch, rather than the patch exposing some other problem.
Would you mind trying my experimental patch to see
Jeremy White wrote:
When did that regression first start? The mmtime and
ntdll/sync.c code has been this way since late last fall.
I'll just mention that, assuming you are referring to this patch:
http://cvs.winehq.org/patch.py?id=14198
it also causes a regression in Myst. Though I am not convince
Jeremy White wrote:
Could you try the attached experimental patch and see
if it eliminates the NFS3 problem?
It fixes the problem in NFS3 when using hardware
accelerated sound. Sound is really messed up when
using HardwareAcceleration = Emulation.
The direct sound regression tests run better in
em
About that time. I believe itunes and some other programs
were seeing 100% cpu usage at that time. Apparently they
got fixed but I was disappointed when the NFS3 problem
didn't go away.
Could you try the attached experimental patch and see
if it eliminates the NFS3 problem?
Cheers,
Jer
? dlls/msi
Jeremy White wrote:
Removing the Yield fixes a regression in Need For Speed III
where the loader and server consume 100% of the CPU. This
is with RH 9 which is a 2.4 kernel.
When did that regression first start? The mmtime and
ntdll/sync.c code has been this way since late last fall.
About that
Removing the Yield fixes a regression in Need For Speed III
where the loader and server consume 100% of the CPU. This
is with RH 9 which is a 2.4 kernel.
When did that regression first start? The mmtime and
ntdll/sync.c code has been this way since late last fall.
The Yield is, imho, correct, exc
Jeremy White wrote:
You might try putting traces around the
conditional YieldExecution on line 730
of ntdll/sync.c and see if that chews up time;
if it does, removing the Yield might help.
Removing the Yield fixes a regression in Need For Speed III
where the loader and server consume 100% of the CP
Hmm. Actually, both cases are broken; you should have a min/max
that hovers right around the target period. This is what I get
on a 2.6.9 kernel:
timer.c:59:wPeriodMin = 1, wPeriodMax = 65535
timer.c:110:period = 1, resolution = 0
timer.c:136:min = 0, max = 2, average = 1.00
timer.c:110:perio
I just posted a revised test which also prints out the standard deviation.
Same results, 1 and 20 ms have a small deviation and 10 ms has a
deviation of around 10.
Jeremy White wrote:
Hmm. When I run it, I see only the expected behavior,
both on a 2.4 and 2.6 kernel.
Here is what I get with an up to date RH9 on a Dell Dimension 8300
with latest CVS:
Without ntdll/sync.c patch:
timer.c:59:wPeriodMin = 1, wPeriodMax = 65535
timer.c:110:period = 1, resolution =
I just posted a simple mmtimer test for the regression tests.
Hmm. When I run it, I see only the expected behavior,
both on a 2.4 and 2.6 kernel.
Note that the resolution setting is completely meaningless;
the only setting that matters is the period.
And, as far as I can tell, it exactly reproduce
Jeremy White wrote:
I'm taking a public thread that I responded to privately back
to public view:
Robert Reif wrote:
Jeremy White wrote:
Putting traces into the mmtimer thread loop shows
WaitForSingleObject is sleeping for about 20 ms and then
calling the callback twice to catch up.
Well, that me
I'm taking a public thread that I responded to privately back
to public view:
Robert Reif wrote:
Jeremy White wrote:
Putting traces into the mmtimer thread loop shows
WaitForSingleObject is sleeping for about 20 ms and then
calling the callback twice to catch up.
Well, that means mmtimer is right.
I'm trying to track down a problem with the direct sound
regression tests when run in emulation mode using the
wave api. I'm getting a lot of FIXMEs and poor quality
playback. The dsound mixer callback routine expects to
be called every 10 ms but is being called twice every 20
ms. Setting the ti
19 matches
Mail list logo
