It does play normally. It is in exclusive, and I selected event. I can't verify it used that event mode, though. So, either
1. fb2k does not check if event mode is supported according to the driver (the driver mis-reports), or
2. fb2k silently moves up to timer mode on a failure (moves up because in my testing, performance is better in timer mode, c.2015)
I could check myself to see if event mode works here. So, looking at the return, for the Xonar this returns an empty variant. In my code, I consider that the same as not supporting it. I looked in the .inf (search for *xonar*.inf in /windows/system32/DriverStore/FileRepoisitory/) and found no entry.
Here is a sample entry in hdaudio.inf that has it (no such entry in xonardx.inf, hence the empty variant returned from the API call to check if it's supported):
To wrap this up: I don't see why one would offer event mode when it doesn't indicate that it will work, especially since timer mode is the better mode, or at least no worse. If you want to know why it could be "better", events have to come from the driver, so this means a kernel-to-user context switch (ring0 to ring3). Timers are in the same context as the programs that use them, so no context switch. All "pretty-sure", there. As to how much impact that has, probably a bit more than the timing's margin-of-error, but in real life, not much.