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

[malc]

On Fri, 2 Oct 2009, Markus Armbruster wrote:

> malc <address@hidden> writes:
> 
> > On Thu, 1 Oct 2009, Markus Armbruster wrote:
> >
> >> malc <address@hidden> writes:
> >> 
> >> > On Wed, 30 Sep 2009, Markus Armbruster wrote:
> >> >
> >> >> Excuse my ignorance on all things audio, but I stumbled over something
> >> >> that could be wrong.
> >> >> 
> >> >> audio_vm_change_state_handler() stops voices when the VM stops, and
> >> >> starts them when it continues.
> >> >> 
> >> >> audio_atexit() unconditionally stops them.  When a stopped VM exits,
> >> >> this stops voices that are already stopped.
> >> >> 
> >> >> Does the audio driver contract allow stopping a stopped voice?  If yes,
> >> >> I figured starting a running voice is fine, too.  If no, we have a bug
> >> >> in audio_atexit().
> >> >
> >> > This should answer the question audio_atexit existed long before vm
> >> > change state handlers. Those were actually added to stop the host from
> >> > looping the same audio fragment over and over again (can/will happen
> >> > with DirectSound, mmapped OSS, fmod too if i'm not mistaken).
> >> 
> >> Just to make sure: Does this mean implementations of audio_pcm_ops need
> >> to cope with stopping a stopped voice?
> >
> > Yes.
> >
> > [..snip..]
> 
> 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.

After some thinking i believe not calling VOICE_DISABLE in atexit is
possible given that s->vm_running is zero.

-- 
mailto:address@hidden