[Qemu-devel] Re: OSS audio debugging

[Qemu-devel] Re: OSS audio debugging

[Mike Nordell]

[-- Attachment #1: Type: text/plain, Size: 3946 bytes --]

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

[-- Attachment #2: oss.c.gz --]
[-- Type: application/x-gzip, Size: 7541 bytes --]

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

[malc]

On Mon, 14 Jun 2004, Mike Nordell wrote:

> 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.

<snip>
>
> 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.
>

Disabling TB chainging helps running DOOM. As for chopyness, DMA buffer
is very small for OSS setting fragsize,nfrags helps.

>
> 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.

You can try UNIVBE, Scitech has a free(both senses) download.

>
> 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.

Default Win98 sound driver does not work indeed, though installing WDM
driver from W2K(as per VMWare instructions) helped a lot. Sounds MUCH
better than in W2K anyway.

>
>
> 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
>

-- 
mailto:malc@pulsesoft.com

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

[malc]

On Mon, 14 Jun 2004, Mike Nordell wrote:

> 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 have tested your changes (after removing TRUE/FALSE winizms). Sound
under DOS is much worse(than stock 5_aqemu) for at least BillG Force and
Last Express.

As for TB chaining, Fabrice suggested this:
<quote>
note: the emulator is slower without TB chaining
@@ -422,7 +432,7 @@
                 T0 = tmp_T0;
 #endif
                 /* see if we can patch the calling TB. */
-                if (T0 != 0
+                if (T0 != 0 && 0
 #if defined(TARGET_I386) && defined(USE_CODE_COPY)
in cpu-exec.c
</quote>

-- 
mailto:malc@pulsesoft.com

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

[Fabrice Bellard]

Mike Nordell wrote:

> 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.

It should work now. The problem was linked to self modifying code and 
cpu interrupts.

DOOM is a rather pathological case for self-modifying code and it slows 
QEMU a lot (although DOOM remains fully playable on my PC). Since only 
some instruction constants are modified in the code, I could optimize 
this case specifically in the dynamic compiler.

Fabrice.

[Qemu-devel] compile error (current CVS)

[Grzegorz Kulewski]

Hi,

I got

gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. 
-I/var/tmp/portage/qemu-cvs-1.5/work/qemu/target-arm 
-I/var/tmp/portage/qemu-cvs-1.5/work/qemu 
-I/var/tmp/portage/qemu-cvs-1.5/work/qemu/linux-user 
-I/var/tmp/portage/qemu-cvs-1.5/work/qemu/linux-user/arm -D_GNU_SOURCE 
-I/var/tmp/portage/qemu-cvs-1.5/work/qemu/slirp -c -o 
nwfpe/extended_cpdo.o 
/var/tmp/portage/qemu-cvs-1.5/work/qemu/target-arm/nwfpe/extended_cpdo.c
gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. 
-I/var/tmp/portage/qemu-cvs-1.5/work/qemu/target-arm 
-I/var/tmp/portage/qemu-cvs-1.5/work/qemu 
-I/var/tmp/portage/qemu-cvs-1.5/work/qemu/linux-user 
-I/var/tmp/portage/qemu-cvs-1.5/work/qemu/linux-user/arm -D_GNU_SOURCE 
-I/var/tmp/portage/qemu-cvs-1.5/work/qemu/slirp -c -o exec.o 
/var/tmp/portage/qemu-cvs-1.5/work/qemu/exec.c
/var/tmp/portage/qemu-cvs-1.5/work/qemu/exec.c: In function 
`tb_invalidate_phys_page_range':
/var/tmp/portage/qemu-cvs-1.5/work/qemu/exec.c:684: error: `env' 
undeclared (first use in this function)
/var/tmp/portage/qemu-cvs-1.5/work/qemu/exec.c:684: error: (Each 
undeclared identifier is reported only once
/var/tmp/portage/qemu-cvs-1.5/work/qemu/exec.c:684: error: for each 
function it appears in.)
/var/tmp/portage/qemu-cvs-1.5/work/qemu/exec.c: At top level:
/var/tmp/portage/qemu-cvs-1.5/work/qemu/exec.c:1046: warning: 
`breakpoint_invalidate' defined but not used
make[1]: *** [exec.o] Bd 1
make[1]: Leaving directory 
`/var/tmp/portage/qemu-cvs-1.5/work/qemu/arm-user'
make: *** [all] Bd 1


when trying to compile from current CVS.


Thanks for your work,

Grzegorz Kulewski

Re: [Qemu-devel] compile error (current CVS)

[vaise]

On Monday 14 June 2004 21:24, Grzegorz Kulewski wrote:
> I got
>
> gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I.
> -I/var/tmp/portage/qemu-cvs-1.5/work/qemu/target-arm
> -I/var/tmp/portage/qemu-cvs-1.5/work/qemu
> -I/var/tmp/portage/qemu-cvs-1.5/work/qemu/linux-user
> -I/var/tmp/portage/qemu-cvs-1.5/work/qemu/linux-user/arm -D_GNU_SOURCE
> -I/var/tmp/portage/qemu-cvs-1.5/work/qemu/slirp -c -o
> nwfpe/extended_cpdo.o
> /var/tmp/portage/qemu-cvs-1.5/work/qemu/target-arm/nwfpe/extended_cpdo.c
> gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I.
> -I/var/tmp/portage/qemu-cvs-1.5/work/qemu/target-arm
> -I/var/tmp/portage/qemu-cvs-1.5/work/qemu
> -I/var/tmp/portage/qemu-cvs-1.5/work/qemu/linux-user
> -I/var/tmp/portage/qemu-cvs-1.5/work/qemu/linux-user/arm -D_GNU_SOURCE
> -I/var/tmp/portage/qemu-cvs-1.5/work/qemu/slirp -c -o exec.o
> /var/tmp/portage/qemu-cvs-1.5/work/qemu/exec.c
> /var/tmp/portage/qemu-cvs-1.5/work/qemu/exec.c: In function
> `tb_invalidate_phys_page_range':
> /var/tmp/portage/qemu-cvs-1.5/work/qemu/exec.c:684: error: `env'
> undeclared (first use in this function)
> /var/tmp/portage/qemu-cvs-1.5/work/qemu/exec.c:684: error: (Each
> undeclared identifier is reported only once
> /var/tmp/portage/qemu-cvs-1.5/work/qemu/exec.c:684: error: for each
> function it appears in.)
> /var/tmp/portage/qemu-cvs-1.5/work/qemu/exec.c: At top level:
> /var/tmp/portage/qemu-cvs-1.5/work/qemu/exec.c:1046: warning:
> `breakpoint_invalidate' defined but not used
> make[1]: *** [exec.o] Bd 1
> make[1]: Leaving directory
> `/var/tmp/portage/qemu-cvs-1.5/work/qemu/arm-user'
> make: *** [all] Bd 1
>
> when trying to compile from current CVS.

"make clean" ?

[OK NOW] Re: [Qemu-devel] compile error (current CVS)

[Grzegorz Kulewski]

On Tue, 15 Jun 2004 vaise@votreservice.com wrote:

> On Monday 14 June 2004 21:24, Grzegorz Kulewski wrote:
> > I got
> >
> > gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I.
> > -I/var/tmp/portage/qemu-cvs-1.5/work/qemu/target-arm
> > -I/var/tmp/portage/qemu-cvs-1.5/work/qemu
> > -I/var/tmp/portage/qemu-cvs-1.5/work/qemu/linux-user
> > -I/var/tmp/portage/qemu-cvs-1.5/work/qemu/linux-user/arm -D_GNU_SOURCE
> > -I/var/tmp/portage/qemu-cvs-1.5/work/qemu/slirp -c -o
> > nwfpe/extended_cpdo.o
> > /var/tmp/portage/qemu-cvs-1.5/work/qemu/target-arm/nwfpe/extended_cpdo.c
> > gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I.
> > -I/var/tmp/portage/qemu-cvs-1.5/work/qemu/target-arm
> > -I/var/tmp/portage/qemu-cvs-1.5/work/qemu
> > -I/var/tmp/portage/qemu-cvs-1.5/work/qemu/linux-user
> > -I/var/tmp/portage/qemu-cvs-1.5/work/qemu/linux-user/arm -D_GNU_SOURCE
> > -I/var/tmp/portage/qemu-cvs-1.5/work/qemu/slirp -c -o exec.o
> > /var/tmp/portage/qemu-cvs-1.5/work/qemu/exec.c
> > /var/tmp/portage/qemu-cvs-1.5/work/qemu/exec.c: In function
> > `tb_invalidate_phys_page_range':
> > /var/tmp/portage/qemu-cvs-1.5/work/qemu/exec.c:684: error: `env'
> > undeclared (first use in this function)
> > /var/tmp/portage/qemu-cvs-1.5/work/qemu/exec.c:684: error: (Each
> > undeclared identifier is reported only once
> > /var/tmp/portage/qemu-cvs-1.5/work/qemu/exec.c:684: error: for each
> > function it appears in.)
> > /var/tmp/portage/qemu-cvs-1.5/work/qemu/exec.c: At top level:
> > /var/tmp/portage/qemu-cvs-1.5/work/qemu/exec.c:1046: warning:
> > `breakpoint_invalidate' defined but not used
> > make[1]: *** [exec.o] Bd 1
> > make[1]: Leaving directory
> > `/var/tmp/portage/qemu-cvs-1.5/work/qemu/arm-user'
> > make: *** [all] Bd 1
> >
> > when trying to compile from current CVS.
> 
> "make clean" ?


No way. This is Gentoo (The best distro in the world)'s automated qemu-cvs 
ebuild. It works this way: I have to type emerge qemu-cvs and it updates 
its private copy from cvs and then copies this private copy to 
/var/tmp/portage/qemu-cvs-1.5/work and builds it there. (It removes any 
files from this dir before copying of course.) So the source is always 
clean (as in the CVS).

But the good news is that Fabrice updated CVS and current version builds 
ok for me.

BTW. I got this ebuild from this list and modified it some time ago to 
work with newer versions (there were some changes to directory structure 
of qemu installation) and I synchronized this ebuild with official qemu 
release ebuilds. When using this ebuild you should put softmmu into USE 
and you should probably NOT put qemu-fast as it is known not to work with 
recent glibcs / binutils / gccs.

I do not remember if I posted the modified ebuild, so here it is:

# Copyright 1999-2004 Gentoo Technologies, Inc.
# Distributed under the terms of the GNU General Public License v2
#
# qemu-cvs-1.3 and previous by Gabriel Ebner <ge@gabrielebner.at>.
#
# qemu-cvs-1.4 Grzegorz Kulewski <kangur@polcom.net>
#       * synced with current (0.5.4 and 0.5.5) release ebuild
#       * some minor fixes
#
# qemu-cvs-1.5 Grzegorz Kulewski <kangur@polcom.net>
#       * fixed access violation with current CVS in make install
#         (added datadir variable)
#       * added qemu-fast use flag (do NOT use it yet!)
#

ECVS_AUTH="ext"
export CVS_RSH="ssh"
ECVS_SERVER="savannah.gnu.org:/cvsroot/qemu"
ECVS_MODULE="qemu"
ECVS_USER="anoncvs"
ECVS_PASS=""
ECVS_CVS_OPTIONS="-dP"
ECVS_SSH_HOST_KEY="savannah.gnu.org,199.232.41.3 ssh-rsa 
AAAAB3NzaC1yc2EAAAABIwAAAIEAzFQovi+67xa+wymRz9u3plx0ntQnELBoNU4SCl3RkwSFZkrZsRTC0fTpOKatQNs1r/BLFoVt21oVFwIXVevGQwB+Lf0Z+5w9qwVAQNu/YUAFHBPTqBze4wYK/gSWqQOLoj7rOhZk0xtAS6USqcfKdzMdRWgeuZ550P6gSzEHfv0="
inherit cvs

S="${WORKDIR}/${ECVS_MODULE}"
DESCRIPTION="Multi-platform & multi-targets dynamic translator"
SRC_URI=""
HOMEPAGE="http://fabrice.bellard.free.fr/qemu/"
KEYWORDS="~x86 ~ppc -alpha -sparc -arm"
SLOT="0"
LICENSE="GPL-2 LGPL-2.1"

IUSE="sdl softmmu qemu-fast"

DEPEND="virtual/glibc
                sdl? ( media-libs/libsdl )
                || ( app-text/tetex app-text/texi2html )"

RDEPEND="virtual/glibc
        sdl? ( media-libs/libsdl )
                !app-emulation/qemu"

RESTRICT="nostrip"

# qemu-fast can NOT be compiled with current Gentoo binutils
# so do not put qemu-fast into use!
TARGET_LIST="arm-user i386-user ppc-user sparc-user"
use softmmu && TARGET_LIST="${TARGET_LIST} i386-softmmu ppc-softmmu"
use qemu-fast && TARGET_LIST="${TARGET_LIST} i386"

src_compile() {
        ./configure --prefix=/usr \
                --target-list="${TARGET_LIST}" || die "could not 
configure"
        make || die "make failed"
}

src_install() {
        # qemu does not use autoconf DESTDIR so we must set all of these:
        # (if this ebuild will break suddenly after qemu CVS change
        # with sandbox access violated error then you probably need to add
        # some new destination variable to make install)

        make install prefix=${D}/usr                    \
                bindir=${D}/usr/bin                     \
                sharedir=${D}/usr/share/qemu            \
                datadir=${D}/usr/share/qemu             \
                docdir=${D}/usr/share/doc/${PF}         \
                mandir=${D}/usr/share/man || die "could not install"

        dodoc TODO VERSION COPYING* README README.distrib *.html
}

pkg_postinstall() {
        einfo "You will need the Universal TUN/TAP driver compiled into"
        einfo "kernel or as a module to use the virtual network device."
}


Does anybody have better or more correct version?


Thanks,

Grzegorz Kulewski

[Qemu-devel] Re: [OK NOW] Re: compile error (current CVS)

[Gabriel Ebner]

Grzegorz Kulewski <kangur@polcom.net> schrieb:
> src_compile() {
>         ./configure --prefix=/usr \

If you want to have USE=sdl working, you'll have to add `use_enable sdl`
here.

>                 --target-list="${TARGET_LIST}" || die "could not 
> configure"
>         make || die "make failed"
> }
>
> Does anybody have better or more correct version?

	Gabriel.

-- 
Gabriel Ebner - dont-send-any-mail-to-this-address@gabrielebner.at
==> Please don't CC me!  I'm reading the list.

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

[Jean-Michel POURE]

Le lundi 14 Juin 2004 21:01, Fabrice Bellard a écrit :
> It should work now. The problem was linked to self modifying code and
> cpu interrupts.

There seems to be a compilation error after last modifications:

make[1]: entrant dans le répertoire « /home/jmpoure/projets/qemu/qemu/arm-user 
»
gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. 
-I/home/jmpoure/projets/qemu/qemu/target-arm 
-I/home/jmpoure/projets/qemu/qemu 
-I/home/jmpoure/projets/qemu/qemu/linux-user 
-I/home/jmpoure/projets/qemu/qemu/linux-user/arm -D_GNU_SOURCE 
-I/home/jmpoure/projets/qemu/qemu/slirp -c -o 
exec.o /home/jmpoure/projets/qemu/qemu/exec.c
/home/jmpoure/projets/qemu/qemu/exec.c: Dans la fonction « 
tb_invalidate_phys_page_range »:
/home/jmpoure/projets/qemu/qemu/exec.c:684: error: `env' undeclared (first use 
in this function)
/home/jmpoure/projets/qemu/qemu/exec.c:684: error: (Each undeclared identifier 
is reported only once
/home/jmpoure/projets/qemu/qemu/exec.c:684: error: for each function it 
appears in.)
/home/jmpoure/projets/qemu/qemu/exec.c: Hors de toute fonction :
/home/jmpoure/projets/qemu/qemu/exec.c:1046: attention : 
`breakpoint_invalidate' defined but not used
make[1]: *** [exec.o] Erreur 1
make[1]: quittant le répertoire « /home/jmpoure/projets/qemu/qemu/arm-user »

Cheers,
Jean-Michel

[Qemu-devel] Re: OSS audio debugging

[Mike Nordell]

malc wrote:

> ... while im figuring this out you can
> try experimental SDL output driver(but see caveats):
> http://www.boblycat.org/~malc/code/patches/qemu/5_aqemu.patch.gz
[snip]
> b. it was hacked in an hour or so and therefore i can not claim that it
>    works all that well, in fact it contains a deadlock

Indeed.

> P.S. Can someone on Windows try this?

Done, and it fails miserably. It hangs QEMU due to the deadlock (NT5sp4 both
host and guest).

One thread is waiting in for the semaphore "s" in audio_callback, called
from SDL_RunAudio in SDL's audio thread, while another thread is doing some
seriously wicked:

dsp_write (sb16.c)
complete (sb16.c)
dma_cmd (sb16.c)
AUD_reset (oss.c)
maybe_open (oss.c)
do_open (oss.c)
SDL_CloseAudio
SDL_QuitSubSystem
SDL_AudioQuit
SDL_WaitThread

The deadlock is of course that the callback thread is hanging in sem_wait()
in oss.c, while the requested shutdown of SDL's audio subsystem is waiting
for that very audio thread to die. Yep, instant deadlock (not to mention a
possibly very slow and heavy-weight operation in response to a virtual SB16
DSP DMA transfer).

Another thing I found odd was the use of AUDIO_S16/copy_u16_to_s16 in
response to a request for AUD_FMT_U16. Any particular reason to not request
AUDIO_U16 and use copy_no_conversion?

Problems set aside, this is a giant leap forward for Win32 host audio and is
something I really want to see get into CVS once cleaned up and debugged.
I'll do some more debugging on my side too.

Thanks!

/Mike

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

[malc]

On Fri, 11 Jun 2004, Mike Nordell wrote:

> malc wrote:
>
> > ... while im figuring this out you can
> > try experimental SDL output driver(but see caveats):
> > http://www.boblycat.org/~malc/code/patches/qemu/5_aqemu.patch.gz
> [snip]
> > b. it was hacked in an hour or so and therefore i can not claim that it
> >    works all that well, in fact it contains a deadlock
>
> Indeed.
>
> > P.S. Can someone on Windows try this?
>
> Done, and it fails miserably. It hangs QEMU due to the deadlock (NT5sp4 both
> host and guest).
>
> One thread is waiting in for the semaphore "s" in audio_callback, called
> from SDL_RunAudio in SDL's audio thread, while another thread is doing some
> seriously wicked:
>
> dsp_write (sb16.c)
> complete (sb16.c)
> dma_cmd (sb16.c)
> AUD_reset (oss.c)
> maybe_open (oss.c)
> do_open (oss.c)
> SDL_CloseAudio
> SDL_QuitSubSystem
> SDL_AudioQuit
> SDL_WaitThread

Thats quite normal chain of events.

>
> The deadlock is of course that the callback thread is hanging in sem_wait()
> in oss.c, while the requested shutdown of SDL's audio subsystem is waiting
> for that very audio thread to die. Yep, instant deadlock (not to mention a
> possibly very slow and heavy-weight operation in response to a virtual SB16
> DSP DMA transfer).

Yeah yeah i know. Thing is, audio callback is in a thread by itself and
when invoked must mix exactly (supplied) len bytes, if pre-buffer does not
have len bytes it must wait - hence semaphore (otherwise choppy sound).
This thing can be implemented with condition variables with predicate that
will check some "die" flag, but conditions on Win32 are much more
heavyweight thant semaphores, besides im not sure that they are
implemented correctly in SDL (Win32).

>
> Another thing I found odd was the use of AUDIO_S16/copy_u16_to_s16 in
> response to a request for AUD_FMT_U16. Any particular reason to not request
> AUDIO_U16 and use copy_no_conversion?

My card does not have U16 :)

>
> Problems set aside, this is a giant leap forward for Win32 host audio and is
> something I really want to see get into CVS once cleaned up and debugged.
> I'll do some more debugging on my side too.
>
> Thanks!

Welcome

-- 
mailto:malc@pulsesoft.com