I’ve reviewed this issue and I can appreciate the difficulties of devices in the wild malfunctioning. Ideally, we’d love to fix the core issue, however, without either you or us being about to reproduce it, the chances of a fix are very slim.
I agree with your assessment of the no-sound fallback needing to be softer. When it was originally developed the idea was to throw a single exception on first access of the runtime manager. That way the issue was raised, then subsequent access of the runtime manager would succeed (in no-sound) allowing the application to continue. However, if that first call stack is critical to your application initialization, the exception will terminate it making the problem unrecoverable. If you have an exception reporter set up, this will log once per game, which may or may not be useful. Also, if you intercept exceptions and terminate the game, then this behavior is a deal breaker.
The simplest fix is to remove the exception, you can do this yourself by commenting out or removing throw new SystemNotInitializedException(initResult, "Output forced to NO SOUND mode") from private static RuntimeManager Instance in RuntimeManager.cs. This should give you the softer behavior you desire and is inline with the change we are planning to make in a future release.
This change will reduce the visibility of the initialization failure and increase instances of your users reporting the game running as silent. The result is still undesirable, but perhaps less bad. To reiterate, we still want to fix this core issue your users are seeing to solve this for good, so if you manage to reproduce it or get some more clues, please pass them on.