2015-11-10 1 views
1

Я работаю над игрой Unity, которая получает сообщения OSC от гарнитуры Muse EEG. Я пробовал две сторонние библиотеки C# для обработки связи OSC, UnityOSC и unity-OSC-receiver. Оба реализуют связь OSC с базовым System.Net.Sockets.UdpClient. Все работает гладко в Windows, но в OSX через некоторое время я просто перестаю получать сообщения каждый раз. Никаких исключений или сообщений об ошибках, никаких указаний на то, что пошло не так, просто молчание.Почему я перестаю принимать сообщения OSC через некоторое время на Mac?

Мое приложение грубо работает следующим образом:

  • Начните нить, порождающий процесс, который работает Muse-IO. Это заставляет гарнитуру начинать отправлять сообщения. После запуска процесса эта нить только охлаждается на process.WaitforExit()
  • Другой поток запускает цикл while - не в MonoBehavior.Update(), это не так быстро, что позволяет получать и обрабатывать сообщения OSC. В обеих библиотеках это по существу сводится к вызову UdpClient.Receive()
  • Игра использует обработанные сообщения в обычном цикле обновления Unity.

Примерно через 120-140 секунд после инициализации соединения поток сообщений останавливается, и до сих пор я не мог понять, почему. Индикатор подключения на гарнитуре остается включенным, но ничто не указывает, что он по-прежнему отправляет данные.

Вещи я исключил:

  • Это не потому, что количество сообщений, или размера сообщений. Если я изменю команду на гарнитуру, чтобы отправлять только несколько категорий сообщений, сокращая общее количество в два раза (от 600/с до 300/с), тайм-аут все равно происходит одновременно.
  • Это не библиотека OSC. Я получаю точные результаты в обеих библиотеках OSC.
  • Это не брандмауэр. Брандмауэр выключен.
  • Возможно, это не тот порт, который используется кем-то другим. Я пробовал разные порты с тем же результатом.
  • Он не является драйвером OSX Muse. Когда я использую их графический интерфейс для визуализации входящих данных, он продолжает получать данные столько, сколько захочу.

Я подозреваю, что Mono, Unity или OSX может быть закрытие (мусор собирающего процесса) Muse-IO или нити, так как время до возникновения проблемы, как представляется, в значительной степени постоянная, независимо от того, что я пытаюсь , Но я не уверен, как дальше диагностировать, не говоря уже об этом. Любые подсказки, предложения или удивительные решения были бы очень желанными.

+0

Я понимаю, что это очень специфическая/узкая проблема, но я действительно надеюсь, что кто-то может мне помочь. Я собираюсь разместить щедрость, как только смогу. – Junuxx

+0

Ну, решил. Я опубликовал решение на случай, если кто-то столкнется с подобной проблемой, но я думаю, что в конце концов не будет ни одной награды. – Junuxx

ответ

0

Я нашел причину.

После нереста процесс ввода/вывода, то поток будет делать

print("Process started!"); 
process.PriorityClass = ProcessPriorityClass.High; 
process.WaitforExit(); 

В ретроспективе, что оператор печати действительно плохо помещается, да ладно. В Windows это отлично работало. Для изменения приоритета процесса требуется только привилегия администратора, если вы увеличиваете его до Realtime, according to the docs. Не так на Mac, хотя. по-видимому, установив его на High, также требуются повышенные права на OSX. Исключительное исключение было тихим/необнаруженным/неотображенным, потому что оно происходит вне основного потока.

Затем, спустя несколько минут, кажется, что поток собран из мусора, включая его дочерний процесс, хотя он все еще работает. Эта задержка действительно отбросила меня, заставив меня искать причину во всех неправильных местах.

уроки:

  • Будьте осторожны с возможными исключениями, когда многопоточность,
  • Не связывайтесь с приоритетом процесса, если вы абсолютно не должны,
  • И никогда не доверяйте документы.
Смежные вопросы