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

[malc <av1474@comtv.ru>]

On Sat, 3 Oct 2009, Markus Armbruster wrote:

> malc <av1474@comtv.ru> writes:
> 
> > On Sat, 3 Oct 2009, Markus Armbruster wrote:
> >
> >> malc <av1474@comtv.ru> 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".

My bad, i meant AudioState's vm_running field.

> 
> Consider monitor command "quit".  All it does is exit(0).  I don't see
> it stopping the VM.

Yes, vm_running would still be 1 (audio's vm_change_state_handler didn't
run, so we will proceed with disabling). 

-- 
mailto:av1474@comtv.ru