Unresponsive Device Driver Service?

[rse]

I'm evaluating AkVirtualCamera under Windows und from a functionality and performance perspective I'm impressed. AkVirtualCamera is exactly what I'm seeking for. Unfortunately, the stability under Windows is still problematic for me. Even with the latest snapshot as of yesterday, I'm regularily see the following scenarios:

1. If I feed frames into the devices via FFmpeg, then start a viewer like SplitCam or OBS Studio I can view the frames just fine. If I now stop the viewer side (just close SplitCam) or even just try to add another AkVirtualCameraDevice, the feeding(!) side gets interrupted as AkVCamManager stream is no longer responsive. The AkVCamManager process seems to be still running, but it no longer is able to send its streams to the camera devices via IPC, as a result no longer fetches data from stdin and as a consequence FFmpeg complains that its buffers are running full. On the attempt to add another camera, SplitCam and OBS Studio when trying to access the AkVirtualCamera devices regularly even crash!

2. Once such problems occurred, even a simple AkVCamManager devices needs about 30-120 seconds to respond. After this time, subsequence command work just fine again, including AkVCamManager stream. If I try to stop the device driver service with "sc stop AkVCamAssistant" it even needs 10-20 seconds until the process is really gone according to the Task Manager. Restarting it with "sc start AkVCamAssistant" then makes everything working just fine again, e.g. AkVCamManager devices then responds again immediately.

From my perspective and observation, there is a problem in the IPC communication or especially in the responsiveness of the camera device driver service itself, because all AkVCamManager commands starve for some time. As it later works again and a restart of the service also helps, I guess some timeouts or buffer flushes or other hang scenarios happen inside device driver.

[rse]

I've tried to get some debug information with AkVCamManager set-loglevel 7 but unfortunately once this is enabled SplitCam and OBS Studio no longer start at all. Seems like they crash immediately. Once I reduce the log-level with AkVCamManager set-loglevel default they at least no longer crash, but wait for a very long time, similar to a simple AkVCamManager devices. Both starve:

Now after about 2 minutes, while I'm still typing this I got at least for AkVCamManager devices:

And now after about 3-4 minutes, everything works again, including SplitCam, which now finally was able to start:

Sorry, I don't know how I can better help from my side, because even the logging makes everything unresponsible. But perhaps you have already a clue what could make the device driver service such unresponsive and starve for a few minutes...

[hipersayanX]

What i do for testing the vcam is that I've the following script for capturing:

#!/bin/sh

ffmpeg -list_devices true -f dshow -i dummy
ffplay -f dshow -i video="Virtual Camera"

and this for testing:

#!/bin/sh

export PATH=/c/msys64/home/user/build-akvirtualcamera-Desktop_Qt_MinGW_w64_64bit_MSYS2-Debug/build/x64:${PATH}
ffmpeg -i ~/video.webm -pix_fmt rgb24 -f rawvideo - | AkVCamManager stream AkVCamVideoDevice0 RGB24 480 360

What I've found, at least in my case, is that the assistant is pretty stable, it didn't randomly crashed for me. But both, the manager and the client did, and I been found was that it was due to the pipe state detection code. Not sure but it could be the same problem for you.

[hipersayanX]

If I feed frames into the devices via FFmpeg, then start a viewer like SplitCam or OBS Studio I can view the frames just fine. If I now stop the viewer side (just close SplitCam) or even just try to add another AkVirtualCameraDevice, the feeding(!) side gets interrupted as AkVCamManager stream is no longer responsive. The AkVCamManager process seems to be still running, but it no longer is able to send its streams to the camera devices via IPC, as a result no longer fetches data from stdin and as a consequence FFmpeg complains that its buffers are running full. On the attempt to add another camera, SplitCam and OBS Studio when trying to access the AkVirtualCamera devices regularly even crash!

This issue should be fixed with latest commit for sure. I still need to test with SplitCam, but the other things should be working well by now.

If I try to stop the device driver service with "sc stop AkVCamAssistant" it even needs 10-20 seconds until the process is really gone according to the Task Manager. Restarting it with "sc start AkVCamAssistant" then makes everything working just fine again, e.g. AkVCamManager devices then responds again immediately.

This problem was probably caused by the loop that was in change of checking the clients status (if they died or are still alive). This should be fixed too.

Once such problems occurred, even a simple AkVCamManager devices needs about 30-120 seconds to respond. After this time, subsequence command work just fine again, including AkVCamManager stream.

If the service is not up, both, the clients and the manager will keep waiting for the service pipe to respond, I don't it as a big issue since the service is a core part of the IPC mechanism, and you are not supposed to stop it, except for debugging purposes.

I've tried to get some debug information with AkVCamManager set-loglevel 7 but unfortunately once this is enabled SplitCam and OBS Studio no longer start at all.

I haven't experienced this bug yet, but you can test latest commit and see if the bug is still there?

[hipersayanX]

OBS is working fine, SplitCam is crashing, I've updated the compatibility table, will try to fix the crash later when I've some time.