From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mt89P-0004t9-CN for qemu-devel@nongnu.org; Wed, 30 Sep 2009 18:59:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mt89J-0004sv-36 for qemu-devel@nongnu.org; Wed, 30 Sep 2009 18:59:58 -0400 Received: from [199.232.76.173] (port=48089 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mt89I-0004ss-Ve for qemu-devel@nongnu.org; Wed, 30 Sep 2009 18:59:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41282) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mt89I-0004gK-Dz for qemu-devel@nongnu.org; Wed, 30 Sep 2009 18:59:52 -0400 Subject: Re: [Qemu-devel] Questions on audio_atexit(), possibly bugs References: <87y6nw9koq.fsf@pike.pond.sub.org> From: Markus Armbruster Date: Thu, 01 Oct 2009 00:59:26 +0200 In-Reply-To: (malc's message of "Thu\, 1 Oct 2009 02\:42\:41 +0400 \(MSD\)") Message-ID: <871vlo9gz5.fsf@pike.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: malc Cc: qemu-devel@nongnu.org malc writes: > On Wed, 30 Sep 2009, Markus Armbruster wrote: > >> Excuse my ignorance on all things audio, but I stumbled over something >> that could be wrong. >> >> audio_vm_change_state_handler() stops voices when the VM stops, and >> starts them when it continues. >> >> audio_atexit() unconditionally stops them. When a stopped VM exits, >> this stops voices that are already stopped. >> >> Does the audio driver contract allow stopping a stopped voice? If yes, >> I figured starting a running voice is fine, too. If no, we have a bug >> in audio_atexit(). > > This should answer the question audio_atexit existed long before vm > change state handlers. Those were actually added to stop the host from > looping the same audio fragment over and over again (can/will happen > with DirectSound, mmapped OSS, fmod too if i'm not mistaken). Just to make sure: Does this mean implementations of audio_pcm_ops need to cope with stopping a stopped voice? >> Why is audio_atexit() needed at all? Doesn't the OS clean up just fine >> all by itself? If we do need manual cleanup, why do we have to stop >> voices before we run fini_out() and fini_in()? > > audio_atexit is needed for WAV, the OS will not write the final > information for us. > >> >> Unrelated, but nearby: audio_vm_change_state_handler() calls the >> ctl_out() callback with three arguments: >> >> hwo->pcm_ops->ctl_out (hwo, op, conf.try_poll_out); >> >> (op is either VOICE_ENABLE or VOICE_DISABLE here), while audio_atexit() >> calls it with two: >> >> hwo->pcm_ops->ctl_out (hwo, VOICE_DISABLE); >> >> Same for ctl_in(). Doesn't look kosher. A quick check of oss_ctl_out() >> and oss_ctl_in() shows use of three parameters. > > Yes, not kosher, but harmless, conf.try_poll_out is only applicable to > VOICE_ENABLE and is simply ignored by the handler of VOICE_DISABLE, this > is a vararg function, so it's okay, though i'd probably change this to > avoid further confusion. Appreciated.