[Qemu-devel] Re: OSS audio debugging

[Mike Nordell]

malc wrote:

> And while im figuring this out you can
> try experimental SDL output driver(but see caveats):

I've made some quite heavy modifications to your SDL audio patch, and from
where I stand it now seems to work. It might seem a bit bloated in places,
and it contains quite a lot of experimental code for tweaking. As the diff
became larger than the file itself, I attached the file.

I'd appreciate reports from both Win32'ers and *nix land using SDL, to see
if there are any SDL differences between platforms not handled.

I've done some testing to validate correctness of not only this SDL audio
"driver" implementation, but QEMU as a whole. Tests have been performed on
Windows 2000 host, therefore obviously only softmmu. I also only tested with
"set SDL_VIDEODRIVER=windib", since DX (the SDL default) is for some reason
for me way slower (and did interfere with keymappings - I haven't bothered
to test pckbd.c CVS, since current setup works for me).
All software tested works on real h/w, and on other emu's.


Comanche: Maximum Overkill - DOS game from 1992.
Tested with all combinations of pci, cirrus-vga and enable-audio.
Works. Fully playable. Audio latency seems to be in the 50-100ms range,
which seems like an acceptable tradeoff between latency and host overhead.


Syndicate - DOS + DOS4WG Game from 1993. Sound works partially during the
introduction sequence (lacking FM-emulation it sounds a bit strange though).
Gets a bit "choppy" and "cracles/pops" due to the fact it changes sample
rate of the SB16 DSP frequently, and closing+opening the audio device is a
quite expensive operation.
Mouse queue is never drained by guest program, why interaction doesn't work
since kbd input hangs when mouse/kbd queue is full. Works with both real h/w
and other emu's. PIC problem?


DOOM Shareware - this one needs no introduction.
Crashes, hangs and plays really "choppy" sound.
The crashes and hangs (depending on moon-phase) seems to be due to
incomplete detection of self-modifying code. When it does run for more than
1 second, the choppy sound I suspect might be, as for many cases here, due
to timing or incorrect SB16, PIC or DMA emulation. That it also run as in
molasses (the seconds I got it to run) further strengthen my suspicions of
timing or PIC - even that it could be a large amount of self-modifying code
invalidating the TB all the time too. I haven't dug deeper into it.


Transport Tycoon
With -cirrus-vga it fails to start with error "Unable to set up SVGA
display".
Without cirrus it switches video mode, but then seems to just hang.


Windows 2000 sp4. Works, except every sound buffer sent (from host to
emulator, I suspect) seems to play twice. Even the "tick" sound when moving
from one folder to another in the Explorer is "echoed". CPU load is not high
during audio playback, why I suspect
timing, PIC, DMA or SB16 emulation problems. Other, larger, waveform
playback sounds horrible due to this echo/reverb effect - and the fact it
seems to not even play at the full speed it should, seems to suggest PIC
problems (interrupt not delivered to guest?).
With my slirp DHCP networking patch, and addition of the NE2000 ASIC writeb
(neither yet committed it seems) it even got an IP from slirp DHCP on every
boot. Never been able to access anything but the host machine itself though,
and then only with a ICMP ping (which slirp rewrites as a UDP ping). DNS
queries do leave host machine and passes through a gateway, and returns, but
never seems to reach the guest OS. TCP socket has never been opened by QEMU
despite attempts.


Windows 98.
Only tested with -enable-audio -cirrusvga -pci -nics 0.
Claims the SB16 device is not functional. The usual suspects. Nothing else
tested.


Even with these problems, I'd say QEMU is starting to become possibly the
best PC emulator there is. As a sidenote I can mention I tested one of the
DOS programs under VMWare. Yep, VMWare crashed allright. ;-P


/Mike

oss.c.gz
Description: GNU Zip compressed data