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

[Markus Armbruster]

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().