Be careful with IDirectSoundBuffer.Lock

[Andru]

Under debugging circumstances you can expect SERR_INVALIDCALL

I expect at least DSERR_INVALIDPARAM, otherwise for what this constant is? Common sense says me that this method should have some checks inside And this a normal return value for many of configurations, but not for ASUS Xonar DS one...

[LP]

I expect at least DSERR_INVALIDPARAM, otherwise for what this constant is?

In my experience, SERR_INVALIDCALL (and its equivalent in WinAPI / DX) is more common when parameters are incorrect, even though there are more meaningful error codes.

Common sense says me that this method should have some checks inside

API and drivers cannot predict all possible invalid values that you can put through this method. Therefore, it is your responsibility to make sure that all parameters are valid and contain meaningful data.

And this a normal return value for many of configurations, but not for ASUS Xonar DS one...

...which is also a normal situation considering that ASUS Xonar DS did not do anything wrong, since they do not need to check for validity of the parameters. The crash is a normal response in this case, which was at your fault for sending invalid data.

Think of it this way: government can make a protection on the trees in case you crash your car into them; however, a more practical approach is to recommend you not to crash your car into the trees and if you crash, it's your fault, not the trees.

[Andru]

...which is also a normal situation considering that ASUS Xonar DS did not do anything wrong, since they do not need to check for validity of the parameters. The crash is a normal response in this case, which was at your fault for sending invalid data.

I would totally agree with this only if I had passed some invalid pointer or whatever else dangerous, but not a "wrong" size, which can be handled without no problems, this is just a zero, even not a negative value... this is almost the same as if that driver can't allocate memory(for sound buffer) and goes crash instead of returning E_OUTOFMEMORY But this thread is not about why I was so careless, just a warning about very specific problem

[LP]

I know and agree with you. My point was that you should not make any assumptions when making API calls. If you see a parameter value that is not documented or its description is too vague, you should take the necessary precautions or better yet, try not to rely on it.

The behavior you described is not an exception, there will be many more cases where you should not rely on API to be "intelligent". So this is as an extension of your warning to the entire API in general, be it DirectSound, Win32 API, DirectX and so on.

This was not always the case, you know. For instance, back in DirectDraw days you could pass the entire structure half empty and DirectDraw will fill in all the remaining values. Now if you try this with Direct3D 11, in the best case you'll get an error code and in the worst case you'll mess up the video driver, even causing BSOD under certain circumstances.