bigpinkdragon286 :
This is not a driver issue.
This is not an issue specific to HDMI.
This is a side effect of using digital audio.
If your amplifier turns off the internal circuitry that receives and decodes your audio signal, that equipment must be woken up, which takes time. It happens on TOSLINK and digital coax as well. This has nothing to do with your graphics card, except it happens to be the device that is sending the audio to the receiver.
The signal being sent to the receiver is a live signal, so unless the receiver has built in buffering and time delay, not something most people want, it can only decode and play back the audio from the point at which it's internal decoder is running again. This is why you lose the beginning of your audio when it starts. Would you really want the receiver to be playing sound from a buffer that could cause synching problems? Probably not.
What is happening when you find a driver that apparently solves your problem? You're actually finding a driver that is forcing your audio equipment in your computer to send a signal constantly, keeping both your computer's audio circuitry active and your receiver's decoding circuitry active. It's not because something was wrong with the other driver, in fact, it's because the other driver is probably adhering to newer standards that let your equipment go into lower power modes more often and save power. Whether this is a real issue or not is case specific, but likely only to make a significant impact to people running their equipment on batteries.
The original solution is actually what I recommend as the best solution, as it addresses the problem directly, instead of as a byproduct of using older driver code. Using older drivers could result in a computer that is less stable, vulnerable to malware attacks, or have other unintended consequences such as being unable to wake from a sleep or hibernation state, or in a worst case scenario, a reinstallation of Windows, if the driver is significantly incompatible.
Using a utility to keep the digital audio connection active, you can actually turn the feature off when you don't need it, and you can retain the benefit of the newer drivers.
To each their own however.
Well, I must disagree with you on this - you're making a number of assumptions on various points here. You're assuming things about power consumption/intended power savings due to nebulous circuitry and the way Windows' audio driver stack handles digital signal to a receiver. You're also assuming that this particular issue is a feature and not a bug, and finally assuming that the driver I've installed is older. I'm open to having my mind changed on all these things, but... you're going to have to help me out with some proof, here! I did my best to do the homework on my own but I can't find anything that supports what you've asserted on the googles.
Were it a SPDIF connection... I'd be more inclined to accept what you wrote at face value. In the case of an HDMI connection, I'd argue that things are a lot different. You already have a signal being sent - the receiver *should* be receiving the necessary stream of handshakes it needs for it to be passing along both audio and video constantly while the signal is active - and in this case, the signal's obviously still active as video persists even when the audio cuts out.
When you're watching a blu-ray or a DVD on any stand-alone dedicated player and you pause the movie - does the audio cut out and re-handshake when you come off of pause, causing you to miss 0.5-1 second of audio playback, or does it just resume playing immediately? I've yet to see one cut out that way when connected to a receiver - and this is the basic problem we're experiencing!
Now, in crazysaguro's case I don't have enough information to dissect the situation properly because it involves completely different hardware than I have, however, I can certainly speak with regards to my situation... even from a purely technical software development standpoint: this behaviour makes the user's life more difficult and is something that was introduced with a later revision of software (specifically software!). That's a bug!
I don't know enough about such specific power saving features in receivers as you've mentioned it might be, but I do know that most receivers have a standby or form of hybrid standby and generally all the power savings have been aimed at keeping the receiver from being too much of a power vampire while still being able to listen for HDMI control signals or network wake-up signals. I'm hazarding a guess that if the receiver is *not* in standby mode, the circuitry you've mentioned is likely engaged/listening already. I can't imagine that having it shut off and have to re-handshake is intended behaviour of any sort, nor would gain any power savings of any worth for that to have been implemented. I looked, but can't find anything that says one way or the other so all I've got to rely on is whatever seems logical. Again, ff you have knowledge I don't, by all means please share.
With regards to driver revisions - this is the latest driver available, included in the same recently released driver package for the card. One is signed for Windows 8.1, the other is signed for Windows 7 - both released on the same day. Basically zero difference otherwise - it's the latest revision available. I can't tell you what one driver is doing differently than the other for obvious reasons. I'd be inclined to think that it has nothing to do with actual signal (as in audible content) so much as something relating to the audio portion of the HDMI handshaking process. Why is that decoupled from the video portion in the Windows 8.1 driver and not in the Windows 7 one? Did they somehow bork up the HDCP component? Is the handshake just not being sent or is it *actively* failing?
As I stated, my solution is one I'd really only ever recommend to an advanced user that knows what they're getting into by mucking with this stuff. I know what I'm doing, but many others don't. You're not necessarily wrong in saying that using a driver that hasn't been signed *could* result in a bunch of unintentional consequences, but in this case I can tell you - empirically - things are working perfectly on this end with a heavy day's load of netflix, spotify and video games under the belt with zero issues.
...I will say though that saying it could result in a reinstallation of windows depending on how "incompatible" it is is a little disingenuous though...! It works or it doesn't. If it doesn't work, Windows will kill the driver or it may cause a BSOD (which will reference the driver at fault directly on the screen or via crashdump). I've yet to see that situation be unable to be fixed by a simple boot into safe mode and pulling the plug from there or even the "Last Known Good Configuration" and I do this stuff for a living.
/blog.rhysgoodwin.com/htpc/spdif-keepalive/ 
Facebook
Twitter