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:address@hidden