For various reasons, I want to hang on to submix voices that may temporarily not be connected to anything. However, I get a debug mode breakpoint when I pass in a send list of 0 voices, and the output in the debugging window is this:

XAUDIO2: ERROR: OutputCount must be greater than zero
XAUDIO2: ERROR: pOutputVoices must be non-NULL
XAUDIO2: ERROR: Invalid pSendList argument

I don't see why setting a voice to send to no output would be invalid. It simply means nobody will ask it for data until it gets re-connected somewhere.

Comments, suggestions or work-arounds?

Hi, you could set the output voice to only the Master voice, maybe?

But that's exactly what I don't want! The output voice of the submix voice is already the master voice. When reconfiguring the network, I'd like to disconnect some voices, and then later re-connect them. I can't really see any good reason why that shouldn't be allowed.

So what's the problem? Do Submix Voices with no input steal processing cycles?

jwatte:

For various reasons, I want to hang on to submix voices that may temporarily not be connected to anything. [...]

Might be worth to share some of the various reasons, e.g. if the gial is to save CPU cycles or it the goal is just to silence the voice(s).

jwatte:

Comments, suggestions or work-arounds?

A hacky(?) suggestion/workaround seems to be to create something like a silencer voice (a submix voice whos volume is set to 0) and use that in the SetOutputVoices call(s).

That's actually a scenario we did want to support.  E.g. so people could host a "sink" effect in a submix which took the input data and wrote it to a file, analyzed it in some way, sent it to a different API or over the network, etc.

The trick is to call SetOutputVoices(NULL), not SetOutputVoices(&SendList) where SendList is empty.

Dugan Porter [MS]
Game Audio Team

I see. That's good to know. It would have been even better had MSDN mentioned that slight detail ;-)
I appreciate your help; thanks!

You're absolutely right - I'll get our docs for this fleshed out.

By the way, any general feedback on patchy or confusing areas in the docs (or for that matter in the API itself) is very welcome.

Regards,
Dugan