Solved! Calling all audiophiles! Windows Sounds cut off w/ HDMI possible S/PDIF keep alive issue

Status
Not open for further replies.

crazysaguaro

Distinguished
May 9, 2006
4
0
18,510
Hello, I've got quite an annoying problem. I'm hooked up from my NVIDIA GTX760 via HDMI to my Bose CineMate 130 receiver (also HDMI). Sounds awesome except for the Windows sounds. The front 0.500ms of each sound is cut off and some shorter sounds do not play at all. This did not happen with my old setup (mobo optical out to a Sony receiver, bypassing the GTX760).

I've done a lot of reading on this & other forums about this issue and it seems it has to do with the S/PDIF output and the receiver taking time to initialize to play the sounds as they start. When I've got it running, this little app seems to fix the issue for me by playing a constant silent sound to keep the receiver/driver active. http://blog.rhysgoodwin.com/htpc/spdif-keepalive/

However, I really want to fix the issue in the NVIDIA GeForce High Definition Audio driver settings, Windows sound settings interface, or both. Is it the NVIDIA driver at fault (needing a keepalive method for S/PDIF sounds)? Or an issue with the Bose CineMate receiver?

Any advice would be appreciated!

Thanks,
Gina
 
Solution
The issue is not with SPDIF (since it worked on your old system) and you are not really using it now. The problem is digital audio over HDMI and the way Bose has set up their receiver. HDMI "handshakes" between devices (coax and optical digital audio do not) and the Bose seems to take a while to detect the audio and looses it if there is no sound for a while Contact Bose and see if they have an answer.
The issue is not with SPDIF (since it worked on your old system) and you are not really using it now. The problem is digital audio over HDMI and the way Bose has set up their receiver. HDMI "handshakes" between devices (coax and optical digital audio do not) and the Bose seems to take a while to detect the audio and looses it if there is no sound for a while Contact Bose and see if they have an answer.
 
Solution

NatoCannon

Estimable
Nov 4, 2014
2
0
4,510
I just wanted to say first - thanks for the link to the small utility, that's an imperfect solution in my eyes, but a solution that works nonetheless and that is FANTASTIC!

Second, I experience the same issue with an Onkyo TX-NR414 receiver and an AMD Radeon 6950 video card... however, here's the kicker: this only started when I recently did an OS upgrade and switched to Windows 8.1 Pro.

Previously, using Windows 7 (Ultimate), the handshake would happen on the first sound played after the computer booted up and then everything would work perfectly after that for the rest of the duration the computer was on. After "upgrading" to Windows 8.1... yeah, the *exact* same issue you reported. Are you also on Windows 8, or are you on Windows 7?

I suppose I wanted to chime in so that you knew that it isn't necessarily *just* an issue with your GeForce, nor is it necessarily an issue with your specific receiver... when this started happening, my first thought was my receiver needed a firmware update and that didn't fix the issue for me. So in this case the only change was software and not hardware.

Unfortunately I don't have a solution just yet but I, too, am on the lookout for a fix and will update if I find anything.

[strike]------------------------[/strike]
UPDATE: well, after a few hours of headbashing I realized the answer was right in front of my face... the Windows 7 driver was working perfectly before. Why wouldn't it work now?

To make a long story short, forcing the old Windows 7 driver to install in Windows 8 has solved my issue... so the root of the problem lies squarely at the driver's/manufacturer's feet. I don't have to use the keepalive utility any longer, however, getting this working was a *huge* pain in the butt and I wouldn't really recommend going through the process unless you're an advanced user and know what you're getting into. To summarize the process:

1) disable driver signing enforcement
2) edit the .INF of the old driver to work properly with Win 8.1 AND remove the driver signature information from it (this makes the driver unsigned and able to be installed on your OS)
3) Install the driver
4) observe it working without the problems with the normal Win 8.1 HDMI audio driver and prematurely celebrate hooray!

...where it got to be a big pain is steps 5 and 6/7/8...
5) permanently disable driver signing enforcement on your Win 8 system so that your driver won't stop working every time you reboot normally
6/7/8) Fail SUPER hard at number 5 despite following all the steps everyone everywhere has posted on the intertrons (goddamnit, Microsoft), proceed to be able to learn about and figure out how to enable test signing permanently, then use a utility called DSEO to "sign" the driver and then use it as normal.

Needless to say I'll report the bug to AMD, but I really don't expect this to be fixed at all nor for anyone else to go through this monumental pain in the butt that I went through... so... there's always Windows 10, I guess.
 

crazysaguaro

Distinguished
May 9, 2006
4
0
18,510


You're welcome, but as you said, it's an imperfect solution. I agree with you that its a driver issue, but I don't think it will be fixed in Win 10. I'm having issues in Win 7, you had issues with Win 8.1 (but can use Win 7 drivers). I think it really just depends on your combo of drivers + receiver. For example, I upgraded to the Bose CineMate and had major issues, but my older Sony receiver handles the sounds just fine with the same Windows HD Audio drivers.

What a frustrating issue!!
 

bigpinkdragon286

Distinguished
Oct 3, 2012
229
0
18,910
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.
 

NatoCannon

Estimable
Nov 4, 2014
2
0
4,510


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. :)
 
Status
Not open for further replies.