[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Questions on audio_atexit(), possibly bugs
From: |
malc |
Subject: |
Re: [Qemu-devel] Questions on audio_atexit(), possibly bugs |
Date: |
Sat, 3 Oct 2009 16:55:30 +0400 (MSD) |
On Sat, 3 Oct 2009, Markus Armbruster wrote:
> 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".
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:address@hidden
- Re: [Qemu-devel] Questions on audio_atexit(), possibly bugs, Markus Armbruster, 2009/10/01
- Re: [Qemu-devel] Questions on audio_atexit(), possibly bugs, Markus Armbruster, 2009/10/02
- Re: [Qemu-devel] Questions on audio_atexit(), possibly bugs, malc, 2009/10/02
- Re: [Qemu-devel] Questions on audio_atexit(), possibly bugs, Markus Armbruster, 2009/10/03
- Re: [Qemu-devel] Questions on audio_atexit(), possibly bugs, malc, 2009/10/03
- Re: [Qemu-devel] Questions on audio_atexit(), possibly bugs, Markus Armbruster, 2009/10/03
- Re: [Qemu-devel] Questions on audio_atexit(), possibly bugs,
malc <=