@Tz2001:
1. Sound: In my system, sound is controlled by Linux. Here is my setup:
Linux (dom0): Asus Xonar Essence sound card connected to a deVa stereo amplifier which drives a set of Celestion SL600 Signature speakers (I spare you the details of the cables). For my music collection I use gmusicbrowser with ALSA in a bit perfect setup and disabled pulseaudio, but that is because I care about sound quality.
Windows VM: I passed through a USB port for a USB sound card - see post & picture here:
http://forums.anandtech.com/showpost.ph ... tcount=128. The headphone output of that USB dongle is then connected to the line-in port of the Asus Xonar. The ALSA mixer under Linux allows me to switch that port on or off, and I have sliders to control the input signal.
Volume is controlled by my amplifier, with the volume slider under Linux turned to maximum. Unless I use headphones, which are controlled by the volume slider under Linux. In the Windows VM I preset the volume for best output quality (if it's too low, you get hiss, if it's too high the result can be distortion).
How does that work? Under Linux, audio works as expected except that gmusicbrowser takes exclusive control of the sound card with no system sounds or other interferences - exactly the way it should be when listening to music
. Bit perfect means there is no resampling of the music material. Of course the music is stored in flac files, i.e. lossless.
When running Windows, the sound output of Windows is multiplexed with the sound under Linux, unless gmusicbrowser is playing music (same as with Linux). So in case I would be gaming under Windows, the sound comes out on the same speakers I use for Linux, together with any sound that's on Linux (except music).
In a normal setup with pulseaudio all sound sources would be multiplexed (and resampled to 48kHz if necessary) so you would be able to listen to music, get system sounds, and for instance play a game in Windows with sound output all at the same time.
This USB sound card may look cumbersome (extra USB port, wiring) but believe me, this is the easiest and cheapest solution to the problem.
Since I have a discrete sound card (the Xonar Essence), I could as well passthrough the onboard audio to the Windows guest and thus use the existing audio ports on the back panel and front (actually, the front headphone/mic connectors are wired to the Xonar). But I had this setup running with the onboard sound before I got the Xonar, so why mess with a perfectly working system?
If onboard sound is good enough for you, get a USB sound stick for Windows. If you prefer better sound quality under Windows, get a separate sound card and pass it to Windows, or pass the onboard sound to Windows and use the sound card for Linux. If you buy a sound card, check the ALSA compatibility list:
http://www.alsa-project.org/main/index.php/Matrix:Main. Or better even, get a good USB DAC:
http://www.stereophile.com/category/com ... o-reviews/. The Dragonfly got good reviews and is still affordable. By the way, USB DACs don't have compatibility issues with Linux, see ALSA page.
2. Power supply: You need to dimension your PSU to meet the power specs of your GPUs and the motherboard/CPU. Haswell CPUs are less power hungry than my Sandybridge-E, which tops the list with 130W TPD. Check the maximum power consumption of all your components, add it up, add some 20-30% spare for future replacements/additions, multiply by 5/4 and get a
gold rated or better power supply whose power rating is equal to or bigger than the result. If everything adds up to 500W (example), a 650W PSU would be enough, but if you want some headroom get a 750W PSU. Don't buy a 1200W PSU just in case (unless you plan 4-way crossfire etc.), as an over-sized PSU will just waste electricity and generate heat.
3. Boot process: Using my how-to, you end up booting into Linux. When you want to run Windows, you would enter the command
to start the Windows VM.
I personally use a panel icon linked to a startup script.
Primary / secondary adapter passthrough: My how-to uses "VGA passthrough to GPU as secondary adapter" which means that the Windows VM first boots using a
virtual Cirrus VGA adapter and, at a later stage during the boot process (when you get the Windows login prompt), switches to the secondary,
real GPU. "VGA passthrough to GPU as primary adapter" means that the Windows VM boots straight away using the real GPU, which is faster and better,
but usually a lot more difficult to make it work. Before I start patching and compiling the Xen sources to make primary passthrough work, I'd rather choose secondary passthrough which usually works "out of the box".
In the end you need to switch your screen input to the graphics card that you use for Windows. Hope that explains it.
Dual-booting is a real pain in the neck and like you I've been waiting for a long time to find a better way. I'm very happy with Xen and VGA passthrough. The only downside to it is that the boot time for Windows is rather long (28 seconds until I get the login prompt). But once logged in everything is up to speed. For all practical purposes I can't tell that Windows is running as a VM. I could have tuned my Windows performance even further, for example by passing through some SATA controllers and perhaps an Ethernet card, but I really don't feel the need for it.
A big bonus of this setup is the ease of backing up the Windows VM, and restoring it when needed. It takes around 5 minutes to restore a 70GB Windows partition (actually LVM volume). And it's easy to switch between Windows and Linux.
. Never mind, it didn't work for me, and the other also reported that it's pretty useless.