There are no artificial slowdowns of any kind. The trial version only locks a few features.
The process of sending the skeleton tracker data is as follows:
- Sensor sends data over USB to NI mate
- NI mate processes this data
- The OSC scripting system on the skeleton tracker page is used to modify these values and form OSC messages (https://forum.ni-mate.com/t/documentation-osc-open-sound-control-and-parameter-tags/282)
- The messages are sent over OSC to the Blender plugin where they are parsed one at a time (one message for each bone) and the data in the scene is updated to match the received values
You said NI mate runs at stable 30 FPS. This means we can eliminate any USB related trouble, which is good - it's really tricky to fix a bottleneck at USB level. This also means we can eliminate the OSC scripting system which can occasionally be slow. The problem is then in Blender in either parsing the OSC messages or updating the scene data / saving the keyframes. It could also be in transmitting the OSC messages themselves, but if this is on the same computer it's unlikely unless something is interfering with the traffic (antivirus or firewall).
Typically a slowdown in Blender can happen if the scene has a large amount of data in it, particularly if there's already animation taking place, requiring the objects to be updated to new poses every frame. The .blend file you linked is pretty light though, so I'm not sure where the slowdown is.
You could take a look at your task manager (Windows) or activity monitor (Mac) and keep an eye on the CPU / Disk usage when you're streaming data to Blender and recording it. Maybe we can get an idea on if the NI mate or Blender process is the one using resources.