I think it's also important to understand the abstraction levels that are involved (although I'm not an expert either).
So you got some nice audio card and put it into your PC, but your system doesn't 'just' work and know how to use that piece of hardware, that's where drivers come in, that provide a common interface between hardware and the OS or similar. At this abstraction level it gets interesting for us programmers, because here we can start calling the driver directly or use some OS specific function or a library (e.g. OpenAL) that does the job for us. That's where C or C++ can show off their powers, because it's here were we can kind of directly access the hardware ('s driver).
The challenge for library builders now start here. Now the problem to include such a functionality in the standard of C++ can be probably split in two. On one side there are so many possibilities, so many different needs and so many different ways that it's nearly impossible to provide such a functionality in as standard. On the other hand C++ has always been a language that was a pure language and is hardware independent. This is one of the main reasons C/C++ runs probably on the most platforms. It doesn't require you to have a CPU of type XYZ or an audio card that follows the specification YX32. C++ is just a language with a standard runtime library for some basic features and at the bottom it's just a specification through a standard. If you'd now go and provide interfaces for specific hardware related stuff, you would not only start limiting the language to a certain platform type, but you'd also break the generality C++ is and has been representing.
So you can basically run C++ on any device for which exists a compiler.
With Java you go one abstraction level higher. The problem with C++ layer is, that every platform is different and thus we need a compiler for every platform. Java's approach is to have an environment that is always (about) the same and thus you can easily go and 'define' that this self-built environment should have an audio interface and then you'll be able to directly integrate it into the language, since you can always assume that there will some sort of audio interface. This 'environment' is then called a VM (Virtual Machine), since you basically abstract a 'standard' PC within your own machine.
So you can basically run Java on any device that provides a Java VM.
Here's a (bad & incomplete) ASCII drawing of the different abstraction levels:
Hardware
|
Driver
|
'OS'
|
Libraries <- Compiler <- C/C++
|
VM <- JIT <- Java
I hope that gave a bit more insight on the workings of a PC.