From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BYYWz-0002Ut-Pr for qemu-devel@nongnu.org; Thu, 10 Jun 2004 19:00:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BYYWy-0002UL-E9 for qemu-devel@nongnu.org; Thu, 10 Jun 2004 19:00:20 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BYYWy-0002U4-As for qemu-devel@nongnu.org; Thu, 10 Jun 2004 19:00:20 -0400 Received: from [81.228.9.107] (helo=av2-1-sn3.vrr.skanova.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BYYVs-0003PQ-Hr for qemu-devel@nongnu.org; Thu, 10 Jun 2004 18:59:12 -0400 Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av2-1-sn3.vrr.skanova.net (Postfix) with ESMTP id BE3F537EE8 for ; Fri, 11 Jun 2004 00:58:48 +0200 (CEST) Received: from putte2k (h151n2fls306o994.telia.com [81.225.243.151]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with SMTP id 9F5C638003 for ; Fri, 11 Jun 2004 00:58:48 +0200 (CEST) Message-ID: <000701c44f3e$882d3fd0$0401a8c0@putte2k> From: "Mike Nordell" Date: Fri, 11 Jun 2004 00:59:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: OSS audio debugging Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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