After solving the installation issues that I've been having recently, I have started to make more use of the WDM Driver again, which has one issue remaining that prevents me from using it as my default sound device:
If the playback device is busy, IPC will stall on "Opening..." indefinitely.
Test conditions:
- Have a Zone Switch rule which routes IPC to its own zone (Zone A) that plays to your sound device (DAC A) with exclusive access.
- Play audio in a separate zone (Zone B) that plays to the same sound device (DAC A) with exclusive access.
- Play audio in some other application on the PC to the WDM Driver e.g. a YouTube video in a web browser.
- Stop playback in Zone B.
Expected result:
- Audio Plays in Zone B.
- IPC tries to play in Zone A but stalls, because the device is busy.
- When playback in Zone B is stopped, IPC audio starts/resumes in Zone A.
Actual result:
- Audio Plays in Zone B.
- IPC tries to play in Zone A but stalls, because the device is busy.
- When playback in Zone B is stopped, IPC remains stuck on "Opening..." indefinitely.
- The only way to get IPC audio playing is to either stop the system audio for 5-10 seconds, or manually stop playback in Zone A—at which point it immediately starts playing system audio.
To be clear: I am aware that MC has "stop rules" for Zone Switch.
The way I have it configured is that any Audio/Video playback inside Media Center is allowed to interrupt IPC playback.
However IPC playback should never be able to interrupt existing Audio/Video playback. (e.g. system audio plays for a background alert and stops your movie)
This one issue is all that remains from making WDM operation seamless.
I don't know what would be the best solution for this, but perhaps any time a stop command is issued—either manually or from a playlist finishing—MC could check to see if IPC is stuck in this "Opening..." state?
Or perhaps it should time-out after 5-10 seconds of not being able to open? As noted above, when I manually stop this stalled "Opening..." instance of IPC, system audio seems to resume immediately.
I don't know which solution would be more resource intensive, or if retrying every 5-10 seconds might cause playback issues during a track change, if it just happens to catch the brief moment between two tracks perhaps.