Still a lot of unanswered questions, but the description of the symptoms is sufficient to let me make some possibly helpful comments.
If you are designing the Windows OS you recognize that 999 out of 1000 users will only be using the audio system to listen to music. They will not care that there is any delay from the time that an audio signal is received somewhere in the computer to the time that it comes out the computer speakers, but they will be very unhappy if the sound is distorted by dropouts. So, since you want them to be able to play their music DVD, use Facebook, check email and run a spreadsheet all at once, you build a humongous audio buffer into the basic audio system. Basic Windows audio is s--l--o--w. And you want to be sure that the average user, not only cannot change the size of that built in buffer, but will not even be able to see it. ASIO, and other low latency drivers are designed to completely bypass the standard Windows audio system and communicate directly with audio applications and the processor (low level access) in order to avoid the latency inherent in the Windows audio system.
Onboard audio typically has the same design constraints and uses a higher latency driver to communicate to Windows. But when you put an audio signal into the audio in of your motherboard and listen to audio out of the motherboard you have little delay. The most likely explantation is that your onboard audio chipset is able to do a connection between its own input and output without actually going through the Windows audio system and its big buffer. That feature is called "direct monitoring" or "zero latency monitoring" when it is described as a feature of an audio interface. The routing looks like this:
audio signal>line in>fast on audio chip turnaround>line out.
The sound setting in Windows control panel box labled "listen to this device" actually should be labeled "listen to this device using the (slow) standard Windows audio system." So checking that box results in a data routing that looks like:
data from input device>Windows audio system>big hidden buffer>Windows audio system>target output device> target device line out. So if that is how you are routing from your onboard audio to the soundblaster, the hidden buffer we were trying to find is built in to the Windows OS itself. No delay until you try to route from the MB input to the soundblaster using Windows. Message: do NOT check "listen to this device" unless you want to add a lot of latency. The test of input into your MB inputs and output via the soundblaster is just uncovering the built in Windows OS buffer.
But if you do not check that "listen to device" box, how will you hear the output? You will not be able to hear it using Windows, but you can still get in and out using a completely separate computer program (more often two programs) that run under windows, like Sonar(1) and an ASIO driver for the soundblaster(2). The routing you want is:
audio signal>Soundblaster line in> ASIO driver>buffers that can be adjusted in size via Sonar>Sonar>CPU for processing with calls to effects and softsynths>Sonar audio track inputs>audio out of Sonar>ASIO driver>Soundblaster>line out of Soundblaster. The Windows standard audio system is not in the routing at all, and you can adjust the ASIO/audio buffers as low as you want so long as your computer can do the processing needed in the time allotted without dropping out.
As fireberd says, there can be complications with using multiple audio interfaces even active at the same time, and it certainly makes troubleshooting more difficult. So if clearing the "listen to device" boxes everywhere is not helpful, open an account with administrator priveledges, go into device manager find and disable any audio devices that are not the Soundblaster driver. If you delete the devices they will not stay deleted when you restart, just disable them. If you have an HDMI video output, you will likely find one or more audio devices you did not know you had, which are the video system audio drivers to send sound over the HDMI cable.
Then to simplify your test setup, just connect the audio out (not USB, not MIDI connector) from your keyboard directly to the soundblaster line in (not to the mixer), create a new project in Sonar that has only one audio track, (no effects) set its input to the Soundblaster, check input echo in Sonar, set the track output to the soundblaster, and connect the Soundblaster line out to the speakers. Hit a key. The delay you hear is all the delay you can blame on the Soundblaster, the ASIO driver, or Sonar. Keep adjusting the buffer in Sonar lower and lower until you get it short enough or you get crackles.
If the system is working in that simple state, start adding things back and testing.