From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mu43e-00057H-JS for qemu-devel@nongnu.org; Sat, 03 Oct 2009 08:49:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mu43Z-00051e-L2 for qemu-devel@nongnu.org; Sat, 03 Oct 2009 08:49:53 -0400 Received: from [199.232.76.173] (port=35988 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mu43Z-00051V-AL for qemu-devel@nongnu.org; Sat, 03 Oct 2009 08:49:49 -0400 Received: from mx20.gnu.org ([199.232.41.8]:15990) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mu43Y-00058j-S5 for qemu-devel@nongnu.org; Sat, 03 Oct 2009 08:49:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mu43Y-0005ZW-65 for qemu-devel@nongnu.org; Sat, 03 Oct 2009 08:49:48 -0400 Subject: Re: [Qemu-devel] Questions on audio_atexit(), possibly bugs References: <87y6nw9koq.fsf@pike.pond.sub.org> <871vlo9gz5.fsf@pike.pond.sub.org> <87tyyhhglx.fsf@pike.pond.sub.org> <87ab08itr0.fsf@pike.pond.sub.org> From: Markus Armbruster Date: Sat, 03 Oct 2009 14:49:32 +0200 In-Reply-To: (malc's message of "Sat\, 3 Oct 2009 16\:21\:54 +0400 \(MSD\)") Message-ID: <87iqewhcbn.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 Sat, 3 Oct 2009, Markus Armbruster wrote: > >> malc writes: >> >> > On Fri, 2 Oct 2009, Markus Armbruster wrote: >> [...] >> >> Thanks. Next question: I'm having difficulties understanding how >> >> HWVoiceIn / HWVoiceOut member enabled works. >> >> >> >> AUD_set_active_out(), AUD_set_active_in() and audio_run_out() take care >> >> to maintain hw->enabled reflecting the state of the voice. They also >> >> use it to avoid changing the state uselessly. >> >> >> >> audio_vm_change_state_handler() uses hw->enabled the same way. But it >> >> doesn't update it. Why? Same for audio_atexit(). >> >> >> > >> > Because it's more or less a hack, just to make sure host doesn't loop >> > the sample it has. Cleaner approach would be to have a member named >> > something like tmporarily_disabled or paused, but that's an overkill. >> >> I think I understand why we disable voices on stop. My question is why >> we don't record the fact in hw->enabled. Care to explain? > > Because of overloaded meaning, here we are only pausing, what enabled > means in other contexts is that all the soft voices are gone or inactive, > so the host should stop. > >> > After some thinking i believe not calling VOICE_DISABLE in atexit is >> > possible given that s->vm_running is zero. >> >> Is it? We call exit() in many, many places... > > Yes. The logic goes like this, vm_stop can be zero only if we saw > vm_change_state_handler going from running to stopped and consequently all > the voices were already stopped/paused - no need to do it at exit. I fear I don't understand. vm_stop is a function, and as such can't "be zero". Consider monitor command "quit". All it does is exit(0). I don't see it stopping the VM.