[sldev] Blowing wind

[Aimee Trescothick]

Nope, that's not it, the two assignments to *cursamplep in the code below are one each for left and right, so writing an interleaved pair to the buffer increments the sample pointer by stride twice, stride is half a stereo pair.

I've just tried testing it by building on Windows and forcing the mixer mode to FSOUND_MIXER_BLENDMODE or FSOUND_MIXER_QUALITY_FPU. Blend mode is a non-starter as it is already marked as obsolete in FMOD 3.75 and forcing it fails, FPU mode results in no audible wind noise at all.

So it really does look like the striding which is only used for these two modes is pointless. My rewritten version works with any mixer mode, so long as long as MIXBUFFERFORMAT is defined appropriately, I guess this is something that has just never worked, and the situations that would need it are so rare now no one's noticed before that it doesn't work.

Aimee.

On 10 Dec 2009, at 15:31, Tofu Linden wrote:

> I don't have time to investigate properly, but my first guess would be
> that this is because our wind is stereo (interleaved
> MIXBUFFERFORMAT_Ts).
> 
> Aimee Trescothick wrote:
>> Can anyone explain how the below piece of the existing code from the wind noise synthesizer has ever actually worked properly, with MIXBUFFERFORMAT_T defined as S16 and stride set to 4 bytes?
>> 
>>    U8 *cursamplep = (U8*)newbuffer;
>> ...
>> 
>>    MIXBUFFERFORMAT_T sample;
>> ...
>> 
>>    sample = llfloor(((F32)nextSample*32768.f*(1.0f - mCurrentPanGainR))+0.5f);
>>    *(MIXBUFFERFORMAT_T*)cursamplep = llclamp(sample, (MIXBUFFERFORMAT_T)-32768,
>>                                                  (MIXBUFFERFORMAT_T)32767);
>>    cursamplep += stride;
>> 
>>    sample = llfloor(((F32)nextSample*32768.f*mCurrentPanGainR)+0.5f);
>>    *(MIXBUFFERFORMAT_T*)cursamplep = llclamp(sample, (MIXBUFFERFORMAT_T)-32768,
>>                                                  (MIXBUFFERFORMAT_T)32767);
>>    cursamplep += stride;
>> 
>> On Windows and Linux MIXBUFFERFORMAT_T is defined as S16, and if the FMOD mixer mode is FSOUND_MIXER_QUALITY_FPU or FSOUND_MIXER_BLENDMODE, stride is set to 4 bytes, as these modes both use a 32-bit mix buffer.
>> 
>> But as far as I can see, that's just going to write signed 16-bit integers into the first two bytes of the 4-byte sample, skipping over the other two bytes, leaving them at whatever they were before (zero, as wind is the first thing that goes in the buffer after it is cleared).  When FMOD tries to read the 4-bytes back as either 32-bit signed integers (FSOUND_MIXER_BLENDMODE), or 32-bit float (FSOUND_MIXER_QUALITY_FPU) that's just going to go horribly wrong.
>> 
>> MIXBUFFERFORMAT_T is only defined as S32 on the Mac, on Windows and Linux it is S16 as one of FMOD's 16-bit MMX mixers is normally used. The only time I would imagine this situation occurs is on a PC without MMX (or when LL_VALGRIND is defined on Linux for testing, which specifically forces the mixer mode to FSOUND_MIXER_QUALITY_FPU).
>> 
>> If this has never worked anyway, it would seem to make sense to turn off the wind generator for these mixer modes to avoid making a horrible noise, drop the striding which will simplify things elsewhere, and just declare cursamplep as MIXBUFFERFORMAT_T in the first place, removing the need to typecast it ... or am I missing something?
>> 
>> (If you followed me this far you're doing better than I am :)
>> 
>> Aimee.