2012-05-15, 12:23
Hello everyone
I recently stumbled on an issue that I didn't have before. My setup uses EventGhost to auto start xbmc when resuming from sleep and my audio is connected through HDMI (AMD HDMI). I'm using Catalyst 12.3.
The issue is that when resuming from sleep it takes up to 10 seconds for the Audio device to go from enabled + "not plugged in" to enabled and "active". I noticed in the XBMC source code that enumeration uses DEVICE_STATE_ACTIVE only as a valid status for the device. As a result of that if XBMC is starting up during that timeframe, it doesn't detect the HDMI Audio device, resulting in no sound whatsoever.
This not being very practical, you can do two things. a) build in a wait for 10 seconds in EventGhost (but how long? maybe there's variance in how quickly the HDMI Audio gets reconnected after wake up?) or b) wait for the device to become active before starting XBMC.
So I wrote a little C++ program that follows the same logic of device enumeration and properties listing (actually textbook example from MS documentation), but as the valid status I took DEVICE_STATE_ACTIVE | DEVICE_STATE_UNPLUGGED, which also gives me the unplugged devices. The program is a command-line console app that takes a few arguments, 1. the GUID of the device you want to wait for, 2. the number of milliseconds between probing the device's status, and 3. the max number of probes. When the app runs, it will probe the device until it becomes "active" and will then immediately exit. I've tried it with my EventGhost setup - so it runs right after wake up and will fire up XBMC as soon as it ends. If anyone interested, let me know I'll post the app on the forum.
This leaves me to think that other people might have the same issue and that allowing "unplugged" devices is something that could potentially be brought into the XBMC code base (as a third option to solve this). This way we wouldn't need this kind of utility anymore. Apparently there's also an event that's being fired as soon as the device becomes "active", so waiting/probing might not even be needed...
Regards - Voyager
I recently stumbled on an issue that I didn't have before. My setup uses EventGhost to auto start xbmc when resuming from sleep and my audio is connected through HDMI (AMD HDMI). I'm using Catalyst 12.3.
The issue is that when resuming from sleep it takes up to 10 seconds for the Audio device to go from enabled + "not plugged in" to enabled and "active". I noticed in the XBMC source code that enumeration uses DEVICE_STATE_ACTIVE only as a valid status for the device. As a result of that if XBMC is starting up during that timeframe, it doesn't detect the HDMI Audio device, resulting in no sound whatsoever.
This not being very practical, you can do two things. a) build in a wait for 10 seconds in EventGhost (but how long? maybe there's variance in how quickly the HDMI Audio gets reconnected after wake up?) or b) wait for the device to become active before starting XBMC.
So I wrote a little C++ program that follows the same logic of device enumeration and properties listing (actually textbook example from MS documentation), but as the valid status I took DEVICE_STATE_ACTIVE | DEVICE_STATE_UNPLUGGED, which also gives me the unplugged devices. The program is a command-line console app that takes a few arguments, 1. the GUID of the device you want to wait for, 2. the number of milliseconds between probing the device's status, and 3. the max number of probes. When the app runs, it will probe the device until it becomes "active" and will then immediately exit. I've tried it with my EventGhost setup - so it runs right after wake up and will fire up XBMC as soon as it ends. If anyone interested, let me know I'll post the app on the forum.
This leaves me to think that other people might have the same issue and that allowing "unplugged" devices is something that could potentially be brought into the XBMC code base (as a third option to solve this). This way we wouldn't need this kind of utility anymore. Apparently there's also an event that's being fired as soon as the device becomes "active", so waiting/probing might not even be needed...
Regards - Voyager
