PDA

View Full Version : Be careful with IDirectSoundBuffer.Lock



Andru
19-03-2012, 05:25 PM
Unfortunately in this world there is no ideal complex software, and sometimes this is very sad. I spent few hours to find what is wrong with my code and finally... I found some stupid bug in sound drivers for ASUS Xonar DS on Windows. In some cases my code tries to Lock (http://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_sdk.idirectsoundbuffer8.idirects oundbuffer8.lock%28v=vs.85%29.aspx) zero bytes for IDirectSoundBuffer, and considering the documentation - it's fine and I should get some error as a result instead of DS_OK. But with some configuration(with disabled "gx mode" for that sound card) I get only a crash. So, be careful and don't try to pass zero to Lock method, because some developers don't know what is standards... :)

AirPas
19-03-2012, 09:17 PM
you mean the buffer or the size ?

phibermon
19-03-2012, 09:43 PM
Cheers for the heads up! yes there are many examples in our lives of driver developers and to some extent hardware designers not following the specs. What seems like a lifetime of GL woes between ATI, Nvidia and various other vendors has left me jaded and bitter. Ok, mainly bitter.

Andru
19-03-2012, 10:02 PM
you mean the buffer or the size ?
I mean second parameter of method Lock (http://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_sdk.idirectsoundbuffer8.idirects oundbuffer8.lock%28v=vs.85%29.aspx) - dwBytes. In some headers for Delphi/FreePascal it named as dwWriteBytes.

LP
20-03-2012, 02:35 AM
The documentation says nothing about dwBytes parameter being zero. Under debugging circumstances you can expect SERR_INVALIDCALL when passing zero, but for retail builds I wouldn't rely on it.

Generally speaking, you should always use common sense when working with API. Check special conditions *before* making API calls and do not test API against special circumstances.

Specifically, drivers have no obligations to check whether the parameters you have passed are correct or not. OpenGL is very forgiving in this case, but DirectX and other related APIs are not, so you need to take extra care yourself.

Andru
20-03-2012, 05:19 AM
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
20-03-2012, 12:43 PM
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
20-03-2012, 01:40 PM
...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
20-03-2012, 01:58 PM
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.