Unity发送TCP MIDI消息控制Allen&Heat设备无效，PacketSender可正常工作

以下是针对你的问题的核心排查方向，从TCP连接、消息传输细节到设备交互逻辑逐一验证：

• TCP连接会话状态不一致
  设备可能要求持续的TCP会话才能接收指令：

  • 检查Unity脚本中TcpClient的生命周期，是否在发送消息后意外关闭了NetworkStream或客户端实例，而PacketSender默认保持连接。确保连接建立后持续维持，直到不需要控制时再断开。
  • 确认设备是否需要心跳包维持连接活跃度，PacketSender可能自带连接保活机制，而Unity脚本未实现，导致设备主动断开会话，后续消息无法送达。

• 消息发送时序与间隔问题
  部分专业音频设备对指令的发送间隔有严格要求：

  • PacketSender是手动单条发送，间隔符合设备处理节奏；而Unity脚本可能批量快速发送，导致设备来不及解析丢包。尝试在每条消息发送后添加短暂延迟（如Thread.Sleep(10)或异步环境下的await Task.Delay(10)），模拟手动发送的间隔。

• 字节流的编码与隐藏细节差异
  即使十六进制显示一致，实际字节流可能存在隐性差异：

  • 核对字节序：部分MIDI协议字段要求大端序，Unity默认的字节处理可能为小端，导致设备解析错误。可通过手动重组字节或BitConverter转换后再发送验证。
  • 抓包对比完整字节流：用Wireshark捕获两者的TCP数据包，检查是否存在PacketSender自动添加的控制字符（如换行、回车）或MIDI帧标记，而Unity脚本未包含这些内容。

• TCP发送缓冲区未强制刷新
  Unity的NetworkStream默认启用缓冲，可能导致消息未即时发送：

  • 在调用stream.Write()后，立刻执行stream.Flush()强制刷新缓冲区，确保消息无延迟地发送到设备。

• 设备的连接权限与握手要求
  设备可能存在会话锁定或认证机制：

  • 测试前关闭PacketSender，确保Unity是当前唯一连接设备的客户端，避免设备拒绝新连接的指令。
  • 检查官方协议是否要求初始握手包（如认证指令、设备初始化消息），PacketSender可能在之前的测试中已完成握手，而Unity脚本未发送，导致后续控制消息被设备忽略。

内容的提问来源于stack exchange，提问作者G. Threepwood