none
simultaneous initialization and access to same Kinect hardware with iNuiSensor poorly behaves and leads to crashes RRS feed

  • Question

  • In SDK v1.5, I have found behavior which is likely errant.

    Using the iNuiSensor interface in C++...

      • it is possible using NuiCreateSensorById() to successfully create two pINuiSensor pointers to the same Kinect hardware
      • it is possible using both those pointers to pNuiSensor->NuiInitialize() with differing initialization flags (for example one init with depth and the 2nd init with depth and color)
      • it is possible using both those now initialized pNuiSensor to pNuiSensor->NuiImageStreamOpen() with different resolutions and data types (e.g. RGB in one and YUV in the other)

    In steps 2 and 3 above, this leads to errant behavior, often to crashes in the hosting application

    If you were in steps 2 and 3 above to send exactly the same parameters, it does not crash. However, the Kinect SDK does not buffer the frames so that each user of pNuiSensor->NuiImageStreamGetNextFrame() gets their own set of buffers. This often leads to one user getting most frames while the other user gets few.

    I am of the opinion that step 2 should fail if the same initialization flags are not passed. Or...the SDK should correctly work in this case. It does not in SDK v1.5.

    I am of the opinion that step 3 should work as long as the same initialization flags are passed. In SDK v1.5, it doesn't.


    --Dale

    Thursday, September 13, 2012 11:30 AM

All replies

  • I had a conversation with some of the Runtime/API team about this:

    you probably are getting the same pointer.  The second nuiinitialize will override the first (that is, it will uninitialize silently, then reinitialize).  Having two threads/components read frames simultaneously will result in one probably getting most of the frames.  This may be entirely expected behavior.  This may be a case where you just need better coordination between components. You can verify that it's the same pointer by just comparing them. BUTwe don’t support multi-threading on INuiSensor.

    Thursday, September 13, 2012 11:54 PM
  • thank you for inquiring into this. For now, I chose to do the following; basically to disallow initializing a sensor that has already been initialized.

    if NuiCreateSensorById()=ok

    if NuiStatus()=ok

    if !NuiInitializationFlags()

    NuiInitialize()

    While allowing a silent reinitialization might be helpful in some case, I would prefer the runtime to return the E_NUI_ALREADY_INITIALIZED constant already defined. This forces the developer to make a conscious choice rather than a silent action. Perhaps an S version of the constant? Silent actions tend to cause silent discovery, like I did, only through testing.

    What about the cases where in my code I never initialize a sensor already initialized. I'm a good citizen. But then some other developer doesn't do the testing that I do and reinitializes my sensor yet I continue to use the sensor as I configured it which likely results in problems with dimensions, stream access, etc.

    Could the API protect dev's more?


    --Dale

    Friday, September 14, 2012 2:13 AM
  • thanks for the feedback, I will add to our backlog
    Saturday, September 15, 2012 10:05 PM
  • What is the status now in Aug 2013? I stumbled upon question what  the recommended way is to reinitialize sensor, when I for example, initially wanted only color stream, and then later need skeleton tracking.

    Friday, August 30, 2013 4:45 PM