Re: fpu controlword altered on windows

On Friday, July 01, 2011 4:36:34 PM Xavier Bouchoux wrote:
> Hi chris!

Hi.

> I discovered a bug in the windows version. The fpu state of the program
> was altered when making openal calls.
> something like this patch is needed:
> 
>   Alc/ALu.c |    3 ++-
>   1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/Alc/ALu.c b/Alc/ALu.c
> index 7cddb5a..2e3f81d 100644
> --- a/Alc/ALu.c
> +++ b/Alc/ALu.c
> @@ -954,7 +954,8 @@ ALvoid aluMixData(ALCdevice *device, ALvoid *buffer,
> ALsizei size)
>       fpuState = fegetround();
>       fesetround(FE_TOWARDZERO);
>   #elif defined(HAVE__CONTROLFP)
> -    fpuState = _controlfp(_RC_CHOP, _MCW_RC);
> +    fpuState = _controlfp(0, 0);
> +    (void)_controlfp(_RC_CHOP, _MCW_RC);
>   #else
>       (void)fpuState;
>   #endif

Hmm. It's my understanding that _controlfp returns the previous state. Down at 
the end of the function, it calls

_controlfp(fpuState, _MCW_RC);

to reset the state back to what it was. Is that not what you see happening?

> Speaking of which, the ALC_SOFTX_loopback_device extension works pretty
> well!
> compared with the tentative version I once sent you, the implentation in
> openAl is indeed much simpler.
>  From the application point of view: it's a bit less transparent than
> just opening a device that does both capture and playback and calling
> alcCaptureSamples(), a specific code path has to be written.
> But on the other hand it's much clearer and robust:
> On the whole I like it better..

The changes needed from regular playback are fairly minor. You need to set the 
format (type+channels) and frequency when creating a context, the refresh/sync 
flags aren't valid, and you need to regularly call alcRenderSamplesSOFT to 
update things, but it should behave normal otherwise.

> The only oddity, I guess, is having to use specific enums
> "AL_STEREO"+"AL_SHORT"  instead of just reusing the same enum as the
> fallback capture device code path, "AL_FORMAT_STEREO16" (which is
> obviously less flexible, but more standard..)

Yeah, I was going for flexibility, so the app has to do as little work as 
reasonably possible between rendering samples and getting them to where they 
need to go. The separate values also allow more formats to be provided without 
exploding the number of format enums (eg, adding floating-point output just 
needs to add an AL_FLOAT enum, instead of AL_FORMAT_*32 enums for each 
supported channel configuration; also makes it clearer, so you're not confused 
about what 8/16/32 bits represent).

I'm not entirely happy with how it is now, though. I don't like using AL_* 
enums for ALC state, so I may rename them (or rather, make copies since the 
AL_* enums are also used for the buffer_samples extension).
_______________________________________________
Openal mailing list
[email protected]
http://opensource.creative.com/mailman/listinfo/openal