Question

我正在C＃中编写一个Kinect WPF应用程序，以便向aLinux C ++应用程序发送手势命令。

我的问题是当Linux应用程序的帧速率低于Kinect（25fps）时，它开始注册命令非常慢。信息发送5秒左右就会发生轮换。从这一点来看，我感觉好像它排空了一些数据包队列，因为它们得到了备份。

由于在Linux端呈现的模型复杂性增加，帧速率下降。

在每个渲染帧中，我检查是否通过select（）和recvfrom（）接收了大约1ms的数据包，然后我解析它。随后更新世界的场景图。在Kinect方面，以25fps的稳定运行正在识别手势数据包。

为什么Linux FPS＆lt; Kinect FPS？它似乎正在执行所有命令，只是在实时应用程序的显着延迟。

此外，有哪些解决方案可以缓解这种延迟？

我认为延迟是由Linux无法处理所有正在发送的数据包引起的，因此数据包会排队。但是，我不确定为什么还有几秒没有更新，尽管技术上每帧读取1个数据包。

这是acode片段。

（每帧执行一次）

  tv.tv_sec = 0;
  tv.tv_usec = 1*1000

      //BLOCKING 1ms  
  retval = select(sfd+1, &fds, NULL, NULL, &tv);

  if (retval < 0) {
     perror("select");
  } else if (retval) {
     int n = recvfrom(sfd, recvbuf, 1024, 0, (struct sockaddr *)&caddr, &len);
     parse_command(recvbuf);
  }

//之后它开始更新/转换世界/场景

谢谢！

Answer 1

有什么方法可以缓解这种延迟？

一种非常简单的方法是使用确认包。发送一堆消息（最多达到选定的阈值，例如，1秒的价值）。只要收到确认数据包，您将继续发送有关Kinect上发生的事件的数据包。如果您没有收到任何确认（因此您的Linux应用程序运行稍稍落后），那么您将丢弃数据直到它赶上（并且您将因为ACK数据包而知道）。

为什么Linux FPS＆lt; Kinect FPS？它出现执行所有命令，只是在a的显着延迟实时应用。

这与您的代码的方式以及执行方式有关。如果没有关于parse_command()功能的任何信息，我们将不知道是什么。是的，您正在执行所有命令，但执行它们的时间太长。在25 FPS，你有40ms才开始看到滞后。在这段时间内，您需要完成所有工作的解析，渲染和命令。

我认为延迟是由Linux无法处理所有问题引起的正在发送的数据包，因此数据包排队。但是，我不是确定为什么尽管如此仍有几秒没有更新技术上每帧读取1个包。

如果不进行一些研究并获得一些确凿的证据，请不要对软件（或任何一般情况）做出假设。 Linux完全能够通过网络接收大量数据。实际上，它非常高效，并且一次可以接收千兆位数据。问题在于客户端代码，而不是内核。

帧率差异和UDP连接

1 个答案: