qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Markus Armbruster
Subject: Re: [Qemu-devel] Questions on audio_atexit(), possibly bugs
Date: Thu, 01 Oct 2009 00:59:26 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)

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?

>> Why is audio_atexit() needed at all?  Doesn't the OS clean up just fine
>> all by itself?  If we do need manual cleanup, why do we have to stop
>> voices before we run fini_out() and fini_in()?
>
> audio_atexit is needed for WAV, the OS will not write the final
> information for us.
>
>> 
>> Unrelated, but nearby: audio_vm_change_state_handler() calls the
>> ctl_out() callback with three arguments:
>> 
>>         hwo->pcm_ops->ctl_out (hwo, op, conf.try_poll_out);
>> 
>> (op is either VOICE_ENABLE or VOICE_DISABLE here), while audio_atexit()
>> calls it with two:
>> 
>>         hwo->pcm_ops->ctl_out (hwo, VOICE_DISABLE);
>> 
>> Same for ctl_in().  Doesn't look kosher.  A quick check of oss_ctl_out()
>> and oss_ctl_in() shows use of three parameters.
>
> Yes, not kosher, but harmless, conf.try_poll_out is only applicable to
> VOICE_ENABLE and is simply ignored by the handler of VOICE_DISABLE, this
> is a vararg function, so it's okay, though i'd probably change this to
> avoid further confusion.

Appreciated.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]