[Qemu-devel] Re: Re: OSS audio debugging

[Qemu-devel] Re: Re: OSS audio debugging

[Mike Nordell]

malc wrote:

> Disabling TB chainging helps running DOOM.

And that would be done... how? Patching the call tb_link(tb) from
cpu_exec()?

> Transport Tycoon
[snip]
>
> You can try UNIVBE, Scitech has a free(both senses) download.

Good idea. Cant understand why I didn't think of Kendall immediately. I
didn't find a free as in speech version, but that's of little concern right
now.

While TT still hangs, it did change display mode - and it also found what I
believe to be more emulation bugs! :-)

During univbe's detection phase (runnning uvconfig.exe from sdd653-d.zip
from scitech's ftp) it wanted to switch video modes a number of times. Turns
out that, at least for Windows host (SDL 1.2.7) using cirrusvga, QEMU didn't
switch display mode (or at least resolution) until i clicked its caption. A
few times I _think_ it switched video mode only once for each caption click,
but mostly it flipped through a bunch of modes - but without me clicking the
caption several times it just hung.

There are two (abstract) possibilities as I see it.
1. It needed a user-generated windows message to go through the message
pump. For a simple mode or resolution switch this seems unlikely, since many
other apps as guests can do mode-switches without any problems.

2. The clicks, which can effectively halt emulation due to the way the
Windows message pump works, can bring down host CPU load from 100% to ~0% -
allowing one of the other threads to run (which seems strange too, since the
timer thread is already running at high priority), and had an effect on
delivery of ... something. Interrupts from the timer thread? I did even make
all accesses to env->interrupt_request thread-safe (they are currently not),
but that didn't change anything. Could be timer dependant, or even a bug in
the uvconfig code, making assumptions about relative CPU + timer speed?

It does however reliably and every time display this error for me - both
with and without pci. It would be interesting to know if anyone can repeat
this on *nix (perhaps both with and without softmmu?). I did multiple runs,
deleting the generated config.dat before each test, and every single time I
got this this behaviour.


> Default Win98 sound driver does not work indeed

If that isn't clear proof the emulation is yet incorrect, I don't know what
is. :-)


/Mike