[bob_loblaw]

I'm using XBMC on Windows with an HDMI video and audio connection. The HDMI cable is connected to an A/V receiver which in turn is connected to my TV.

If, when watching a video through XBMC, the input changes (either to another HDMI input or to a non-HDMI input), upon return XBMC is playing the video extremely slowly and without sound.

Pausing/unpausing makes no difference. Stopping/restarting fixes the video speed but sound does not return and I get an "unable to initialise video" error.

If I either quit and restart XBMC, or change the Audio input from "HDMI Device" to "Primary Sound Driver" (which is the HDMI audio anyway) the audio will return until the input changes again.

However, if I use a different media player, such as MPC-HC, both video and audio resume successfully when the input returns to the HTPC. Note that I only tried in windowed mode with MPC-HC and fullscreen mode (actually, not fullscreen mode but with the resolution the same as my desktop) in XBMC.

Is this a known issue or is there a known fix in XBMC? I don't really want to run something like HDMIOn at a regular interval in case some switches input either on purpose or accidentally as other applications manage to resume upon input changes just fine.

[bob_loblaw]

So no one has seen this issue at all? Really? It's easy to replicate if you have an HDMI output and HDMI display.

[stilger]

I have this same problem. I have HDMI coming out of a 780g motherboard into a Onkyo receiver then to a 1080p TV via HDMI. I am currently passing the sound through the receiver to the TV via HDMI. Once I get my speaker wire run I will not pass the sound through to the TV. My problem normally happens after the TV has been off for sometime. When I turn it back on I get no sound. If I reboot the sound will start working when it plays the logoff sound and will work once it is rebooted. I will try today to restart XBMC instead of rebooting and see if that fixes it.

[bob_loblaw]

Mine is connected from an Intel G41 (?) motherboard to a receiver via HDMI which is directly connected to the speakers. The receiver is connected to the TV also via HDMI but that's not really relevant here in my instance.

Stilger if you connect to the TV directly with HDMI (just as a test) does the same audio dropout happen? What about if you use a different application (I tested with Media Player Classic - Home Cinema: http://mpc-hc.sourceforge.net/ which worked fine when the HDMI input was switched).

This is a problem for me because when powering up the components using a macro on my remote the HDMI input needs to be switched back and forth. Actually, not so much a problem for me as it is my wife.

[bob_loblaw]

I've tested this with builds r19378 and r19715 and it is a problem on both.

[zyxel13]

Hello,

this issue has been reported many times but it is always ignored from the developers, donno why....

In my opinion it is a severe issue for a HTPC Software, to have to restart xbmc if you change tv channel when the HTPC is connect to the TV via HDMI.

More description here :
http://forum.xbmc.org/showthread.php?tid=46666

Here the link to the Debug Log:
http://www.grsnet.net/xbmc/xbmc-hdmi_problem.log




Cheers,
Konstantin

[supernoman]

I think it has to do with the HDMI audio handshake between system and tv/receiver. I know it takes a while for my Onkyo to negotiate audio from the PC but I'm not sure if it's XBMC's fault.
I have also had different experiences based on ATI or Nvidia HDMI. ATI will send "silent" audio to keep the HDMI communication up while Nvidia cuts off audio when there is none so my Onkyo loses audio if I'm not playing anything or moving the cursor.
My two workarounds is to restart XBMC (which I have set to a Eventghost macro) or play a DTS audio file. This will force my receiver to renegotiate audio type with the PC. I normally just restart XBMC. I did notice severe video stuttering if audio isn't working right in XBMC.

[zyxel13]

Hello supernoman,

it has to be a xmbc problem, cause it happens ONLY with XBMC !!!
See here pls:
http://forum.xbmc.org/showpost.php?p=296904&postcount=8

Cheers,
Konstantin

[bob_loblaw]

this issue has been reported many times but it is always ignored from the developers, donno why....

At least it's a comfort knowing others have the same issue. Was thinking for a second I was the only one who'd seen it occur.

It's definitely related to XBMC since using Media Player Classic HC I can switch inputs away from the HDMI it's using (whether it's a different HDMI or non-HDMI input makes no difference) and the audio continues playing just fine and the video doesn't chug like it does with XBMC.

Has the issue been reported in Trac (or Bugzilla or whatever the project is using)?

[phi2039]

The problem here has to do with the way HDMI audio devices are handled by Windows. Since you truncated the debug log, I do not know what Windows version/SP you all are running, and will have to guess. Regardless, when the input is 'switched', what really happens to the PC is that the connection is broken. This causes Windows to remove the device from the list of available hardware. If you were to look at the Device Manager after changing inputs on your receiver, you would see that the HDMI audio device is gone. The trouble with the XBMC code in this regard is that it initializes a given device only once, and reinitialization is done only if the selected output device is changed. The single initialization is a carryover from the xbox, where there was only one device. This single instance is shared application-wide, because the nav sounds (clicks, etc...) use it as well. I will have a look and see what, if anything, can be done with out causing major disruptions on the other platforms.

[zyxel13]

Hi Phil,

well I didnt truncated the Logfile in purpose...., just copyed the file form the HTPC to my Upload directory.....anyway I use WinXP Pro, SP2 :-)

A Intermediate perhaps solution (till the problems is correctly fixed) could be, to make a function (taht can be maped to a key on the remote) that forces xmbc to reinitialize the audio device(s).

What do you say ?

Cheers,
Konstantin

[bob_loblaw]

The problem here has to do with the way HDMI audio devices are handled by Windows. ... when the input is 'switched', what really happens to the PC is that the connection is broken. This causes Windows to remove the device from the list of available hardware. ... The trouble with the XBMC code in this regard is that it initializes a given device only once, and reinitialization is done only if the selected output device is changed.

I suppose the question is: What do other applications do? How do they manage this, because MPC-HC has no problem picking up when an HDMI handshake reoccurs.

Does the Linux port have the same issue?

I think the most difficult thing here will be dealing with how Intel, ATI/AMD, Nvidia all determine when an HDMI connection returns.

What does XBMC do if the audio device is no longer available? Does it just keep outputting blindly and not even check? Could a check done every keyframe or other interval (maybe only if an HDMI was selected)? An option may be required to specify whether a different input is chosen (maybe Primary/Secondary inputs) or whether the system pops up a message or whether it just continues, trying to resume it.

What about how the video suddenly plays at 1/3 (or 1/4 or 1/2, whatever) speed when the sound cuts out? Any idea on that? It can't be fixed by pausing/resuming but can be by stopping/restarting.

[Snowplow]

I have the same issue. I just bought a Dell Studio 540 and I'm using the latest XBMC for Windows on Vista 32-bit. I'm using the onboard HDMI for Audio and Video. It's that same Intel G something mentioned by someone else. I don't have access to the system right now to export a dxdiag.

I have an Elite Pioneer AV Receiver that the PC is hooked to.

My work around has been to turn off and back on the AV Receiver.

If I remember when I get home I'll pump out the dxdiag and post it.

Good question... what do other applications such as MS MC do?

I finally retired my Modded Xbox and am using this new PC as the replacement.

Thanks for a great piece of software that has brought joy for many years

[ArtVandelae]

Gefen makes a device called the HDMI Detective that goes between the PC and the HDMI output device. It basically sends a fake EDID signal all the time so that the PC thinks it's always connected to a fully-featured output source. The only problem is that they are rather costly for what they do.

[phi2039]

The other applications are using DirectShow (a Windows-only API) to handle audio output. I can only imagine that the switching is being handled behind the scenes. This is not a problem on Linux or OSX, adn varies by audio chipset, as my Realtek onboard HDMI works without incident on Vista.

@bob_loblaw: I would suggest that you familiarize yourself with the intricacies of audio handling on Windows before you comment on whether or not the code 'just blindly' does anything. Much effort and thought has been put in place to make the code as robust as possible, given the tools that are available.

Video playback is synced to the audio stream, therefore any disruptions will cause video to begin trying to catch back up.

The device can be forced to reinitialize by selecting a difference audio stream in the OSD menu or by changing from Digital to Analog and back again.

One last question I have is in regard to when the output is being disconnected. Are you changing sources mid-playback or between videos? The partial logfile is inconclusive.