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

[malc]

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.

-- 
mailto:address@hidden