Re: [Qemu-devel] Questions on audio_atexit(), possibly bugs

[Markus Armbruster]

malc <address@hidden> writes:

> On Sat, 3 Oct 2009, Markus Armbruster wrote:
>
>> malc <address@hidden> 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.