KPA-RM interaction problems

Stability has been and is still an issue with a KPA hooked up to a computer. Can anyone shed some light on how this is implemented and why it it so hard to fix the problem?

I've been involved with networking and related software on all kinds of problems for decades and find it peculiar how the KPA often freezes if there is a problem with an attached computer. Any communications-protocol such a the interface between the KPA and RM should define reasonable response-times for any message og set of messages, and be able to gracefully abort. In my work it has been considered unacceptable for any node to stop working if any one of its peers fail to provide a timely and/or correctly formatted response. If a peer fails it should be flagged as disconnected and required to reconnect properly. Why doesn't the KPA behave this way? Is it based on some OS that is incapable of non-blocking communications over USB?

I did place a ticket about this a couple years ago, but have since deleted the email-responses from my archive. Never registered any responses beyond the automated response. The behaviour of the KPA wrt USB-comms hasn't changed noticeably with the last few firmware updates. I mostly run release software, only occasionally testing a beta if there are new features I want to try out. When a computer (Macbook Pro) running RM is connected and it for example goes into hibernation the Kemper may freeze at any time. Sometimes it is enough to pull the USB-cable to get the KPA going again, but a reboot may be required. Currently this isn't critical, as one has to keep the KPA close by for access to its front-panel for many editing operations. It will get a lot worse in studio-settings in the future when many producers will prefer to put the KPA away, maybe in a different room, and control it with the new editor / rig-manager from their audio-workstation or other computer on their desk. Already it is annoying if the attached computer decides to hibernate causing a freeze in the middle of a recording-session. Most of the time fortunately it is only the UI on the KPA that freezes while it keeps producing sound.

It is not only my KPA that behaves this way, so I believe a hardware failure is out of the question. Recently I brought a stick with a backup to a studio that had their own KPA and got the same problem there. On my own KPA I have tried to reset everything to factory defaults but the unit behaves exactly the same without any changes from the factory setup.

I have a feeling that the freezes may be a little less frequent than say two years ago, but then I also try to avoid connecting my KPA to a computer unless I really need to so this is just a subjective opinion. The last couple times it has happened to me the UI has had some form of FX-editing open for tuning of parameters. My thoughts were that maybe non-blocking I/O were implemented as an afterthought, but that certain types of messages in certain situations still hasn't been included. These are just guesses based on my own developer experience.

My opinion as a developer is that any network node needs to be implemented such that its peers are unable to influence its operation. You can not protect against a peer maliciously abusing a protocol using valid messages/instructions. Incomplete messages, faulty messages and failures to respond or complete a message within reasonable time OTOH must be dealt with. The attached computer should be able to throw anything at the KPA, except deliberate malicious messages, with no consequences. A peers failure to respond timely to a message should not cause any problems beyond possibly an error message if that is appropriate for the situation. The KPA should not be affected if RM suddenly stops responding because a screensaver is kicking in on the computer or the computer goes into hibernation with its USB-interface still active.

ticket was filed just prior to my last message with the same content.