[PATCH 4/5] dsound: Add support for OpenAL IDirectSoundCaptureBuffer

Maarten Lankhorst m.b.lankhorst at gmail.com
Tue Dec 1 02:14:56 CST 2009


Hi Chris,

Chris Robinson schreef:
> On Monday 30 November 2009 1:56:20 pm Maarten Lankhorst wrote:
>   
>> +    if (This->playing)
>> +    {
>> +        pos2 = This->format->nSamplesPerSec / 100;
>> +        pos2 *= This->format->nBlockAlign;
>> +        pos2 += pos1;
>> +        if (!This->looping && pos2 > This->buf_size)
>> +            pos2 = 0;
>> +        else
>> +            pos2 %= This->buf_size;
>> +    }
>>     
>
> Does non-looping capture let the write position get to This->buf_size? It 
> looks like a position of This->buf_size should set the position to 0 too, if 
> This->buf_size+1 would.
>   
It's handled properly with the modulus.
>> +        if (format->wFormatTag == WAVE_FORMAT_EXTENSIBLE)
>> +        {
>> +            WAVEFORMATEXTENSIBLE *wfe = (WAVEFORMATEXTENSIBLE*)format;
>> +            if (!IsEqualGUID(&wfe->SubFormat,
>> &KSDATAFORMAT_SUBTYPE_IEEE_FLOAT))
>> +                return DSERR_BADFORMAT;
>> +            else if (format->cbSize < sizeof(WAVEFORMATEXTENSIBLE)-
>> sizeof(WAVEFORMATEX))
>> +                return DSERR_INVALIDPARAM;
>> +            else if (format->cbSize > sizeof(WAVEFORMATEXTENSIBLE)-
>> sizeof(WAVEFORMATEX)
>> +                && format->cbSize != sizeof(WAVEFORMATEXTENSIBLE))
>> +                return DSERR_CONTROLUNAVAIL;
>> +        }
>>     
>
> You should probably check the cbSize before accessing the extended 
> information, otherwise it may indicate that there isn't enough space for the 
> extended information. Also, is it necessary to reject formats with a higher 
> cbSize than needed (IIRC, Wine's tests showed some Windows versions allowed 
> it)?
>   
Woops, mild oversight there. cbSize is allowed to be 
sizeof(WAVEFORMATEXTENSIBLE)-sizeof(WAVEFORMATEX), or 
sizeof(WAVEFORMATEXTENSIBLE) (sloppy programming), but the error 
checking is a lot stricter compared to WAVEFORMATEX, so this is correct.
>> +    buf_format = alGetEnumValue(fmt_str);
>>     
>
> Unfortunately, you can't call this function when a context is not set (it'll 
> probably work on some systems, but technically shouldn't). And setting a 
> context makes no sense for capture. Setting buf_format directly to the enum in 
> the switches should be all you need to do.. just make sure to initialize it to 
> 0 so the check won't use it uninitialized.
>   
Theoretically you're right. I'll send an updated version.
>> +    This->dev = alcCaptureOpenDevice(This->parent->device,
>>  This->format->nSamplesPerSec, buf_format, This->buf_size);
>>     
>
> Note that the buffer size given to OpenAL is in sample frames, not bytes. It's 
> not a direct problem here, per se, but it may be an issue if a large size is 
> requested (ie, where n samples would work, but n*2 or n*4 won't)
For bigger buffers we should probably just request up to a 500 ms buffer 
top, but I suppose there's no harm in wasting some extra space, as long 
as it's not excessive. I'll call it with buf_size / nBlockAlign for now, 
if an application requests a huge buffer and the code breaks, I will 
revisit this again. :)

Cheers,
Maarten.






More information about the wine-devel mailing list