Results 1 to 9 of 9

Thread: Be careful with IDirectSoundBuffer.Lock

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1

    Be careful with IDirectSoundBuffer.Lock

    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 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...

  2. #2
    you mean the buffer or the size ?

  3. #3
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    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.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  4. #4
    Quote Originally Posted by AirPas
    you mean the buffer or the size ?
    I mean second parameter of method Lock - dwBytes. In some headers for Delphi/FreePascal it named as dwWriteBytes.

  5. #5
    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.

  6. #6
    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...

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •