Jump to content
Posted 27 June 2012 - 08:55 AM
Posted 28 June 2012 - 01:05 AM
Of course not.
streaming an ogg/vorbis was like 1% CPU usage for the entire app, so is that a problem anyway?
Hopefully worker threads won't destroy a voice just because they think is reasonable. Your code must be integrated. And you cannot just have sources anyway (perhaps another component needs to compute occlusion, or a path or whatever...) so some synchronization is necessary.
The problem I'm having with this design is one of resource management. Mainly at the point of destroying a voice (either from the game code, or via one of my worker callbacks) how to ensure this resource is no longer accessed (e.g. due to another callback that was already pending). I think I might be able to make it work with appropriate locks and a way to cancel scheduled tasks (i.e. remove them from the task queue without executing), but I can see that getting very complex design wise.
Posted 28 June 2012 - 03:36 AM
Edited by SyncViews, 28 June 2012 - 03:40 AM.
Posted 29 June 2012 - 01:11 AM
No. It's not a full poll. I don't need the full information to drive this. As a side note, while the check granularity is the same **in the current implementation** event-based allows much higher precision, in case I need it in the future.
Not sure what good an atomic swap does you in the callback if the game has to poll the status of your buffer anyway? Doesn't XAUDIO2_VOICE_STATE give you that info without the callback if your polling (as per my code snippets)?
It appears I haven't got the point across. 1st: no need for worker threads to manage 1% load. 2nd: your code must be integrated so this does not happen. In my case this does not happen because the playing and the decoding are effectively decoupled.
so the problem is what to do with callbacks on my worker thread