From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mu35s-0007Gd-HI for qemu-devel@nongnu.org; Sat, 03 Oct 2009 07:48:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mu35n-0007GR-L2 for qemu-devel@nongnu.org; Sat, 03 Oct 2009 07:48:07 -0400 Received: from [199.232.76.173] (port=49833 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mu35n-0007GO-Es for qemu-devel@nongnu.org; Sat, 03 Oct 2009 07:48:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1124) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mu35n-0002s3-0d for qemu-devel@nongnu.org; Sat, 03 Oct 2009 07:48:03 -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> From: Markus Armbruster Date: Sat, 03 Oct 2009 13:47:47 +0200 In-Reply-To: (malc's message of "Sat\, 3 Oct 2009 01\:26\:36 +0400 \(MSD\)") Message-ID: <87ab08itr0.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 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? > 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...