From: malc <malc@pulsesoft.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: OSS audio debugging
Date: Fri, 11 Jun 2004 09:23:44 +0400 (MSD) [thread overview]
Message-ID: <Pine.LNX.4.55.0406110917570.563@home.oyster.ru> (raw)
In-Reply-To: <000701c44f3e$882d3fd0$0401a8c0@putte2k>
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
next prev parent reply other threads:[~2004-06-11 5:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-10 22:59 [Qemu-devel] Re: OSS audio debugging Mike Nordell
2004-06-11 5:23 ` malc [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-06-14 7:57 Mike Nordell
2004-06-14 9:02 ` malc
2004-06-14 15:56 ` malc
2004-06-14 19:01 ` Fabrice Bellard
2004-06-14 19:29 ` Jean-Michel POURE
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.55.0406110917570.563@home.oyster.ru \
--to=malc@pulsesoft.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).