No such problem reproducable. MIDI is not audio, that error message would only make sense with FX enabled . Turn off Echo and Reverb to check if it works then.

Are you on the current firmware and driver (1.113)?

EQ doesn't matter. Disable the WDM devices for a test (in Settings dialog). This might be a WDM audio problem, not directly related to the BF.

I wrote: Disable the WDM devices for a test (in Settings dialog). Much quicker, easier and more relevant than your method.

In your notification area. Manual chapter 8. Configuring the Babyface -    8.1 Settings Dialog. The WDM option came in a later driver, set it to 0 and change the sample rate one time to remove all WDM devices.

Any news if my problem is reproducible on your end?  If it only happens here then I am thinking of doing a clean windows install.  Thanks

I just reinstalled windows 10.  Clean install, from a newly created boot USB flash drive, with all settings reset to default before restarting (they are now synced), wiping all partitions and reinstalling.  After it installed I updated it, installed my drivers including RME Babyface and did the exact same test.  There is no change, the computer can enter sleep normally, and as soon as both of the settings in the following picture are chosen, the computer cannot sleep.  I have two computers, completely different configurations, with two different RME Babyface interfaces.  There is nothing running on either computer when I test.  I have reinstalled windows on one of the computers, but I can do the same on the other one, if needed to confirm.

This is what Command Prompt shows:

the computer with newly installed windows 10:
GIGABYTE GA-X99P-SLI
Intel i7-6800K
32GB RAM
EVGA GeForce GTX 1070

other computer also running windows 10:
MSI P6N SLI Platinum
Intel Core 2 Duo E6600
8GB RAM
MSI GeForce GTX 1030

The only things similar between the computers are the same Nvidia driver for the GPUs and Logitech driver for the mice.

Edit: There is nothing connected to the MIDI in connector, if that makes any difference.

Edit 2: Besides the different hardware, which might not be relevant, since I have two different configurations that show the exact same result, another variable is windows 10 versions and updates.  This could explain why the problem is not reproducible on your end and why nobody ever reported such behavior.  I noticed big differences between windows 10 major updates.  Is it possible that something in windows 10 is causing this problem?

I can confirm that 'powercfg -requests' gives the same message on my computers (An audio device...although this is clearly MIDI). Anyway, in both cases sleep still works...

Thank you for this explanation.  Any idea why sleep works on your computers, and not on mine?

I found a way to force windows to ignore Babyface driver https://en.wikipedia.org/wiki/Powercfg by typing powercfg -requestsoverride DRIVER "RME Babyface" SYSTEM, is this the best way to do it?

pianopictures, thank you for your reply.  If it won't be too much trouble, can you open command prompt as admin (hit start, type CMD, right click and run as admin) and type "powercfg -requests" without the " after your computer wakes from standby, and post if you see anything other than None.

I mean it can't go into power saving mode (standby/sleep)  by itself after whatever minutes are set in windows power options.  It is easy to test when you set both "Turn off display:" and "Put the computer to sleep:" at 1 minute in Control Panel\Hardware and Sound\Power Options\Change plan settings.

Edit:  On mine the monitor turns off, as it should, but the computer does not enter standby/sleep.

I'll also check that later - never tried it that way.

Thank you. I'm happy that I actually found something worth writing about here.

Unfortunately we were not able to find a quick fix for this behaviour. The MIDI port used blocks Standby via the system itself, and we don't have control over that. A possible workaround would be that we disable MIDI as soon as Standby shutdown queries arrive, but this needs more time and testing. If our disabling of the MIDI port happens after the OS queries its MIDI subsystem it would not work at all...or only on some machines, timing dependent...