Supports 4-channel WAV files, presumed to be B-format (FuMa) first-order Ambisonic.
Supports WAV with arbitrary sample rate (needs optimization).
Supports soundfield volume and orientation set via script.
Supports localOnly client-side injection using simple (non-spatialized) test renderer.
Seems there were 2 issues:
* If you couldn't inject locally (say, no audio interface
because you are an assignment client), we would not do the
network injection at all. That's bad.
* When we don't have a codec, like when using an injector, we
were serializing the empty string in some problematic way. I
just use the built-in serialization, and it seems fine.
I tested this by first playing a sound in the console (or maybe you
want to tip some cows, that is ok too). Then in _another_ interface
client on another machine in the same domain, I better hear the
sound.
Then, I added a script to play audio as a persistent script, which
just loops forever and ever. You should hear that on both interface
clients also.
A detailed test plan to follow.
Also: using @zappoman serialization code, which is safer than using
the Qt code which does magical things for nulls. Good to do this cuz
you know, things happen...
When I "fixed" my or instead of and issue, I did it in the wrong
direction. But it looked right :) Now it is. Sigh. Long story
how it got there, but it seems good now.
Code a bit more readable. Sadly (and I guess it makes sense), a
enum class XXX is not a class, so you cannot have member functions
for it. I can imagine no way to have a vtable if you are really
representing it as a uint8_t or whatever. So, I put a stateHas
function in the AudioInjector instead. Definite improvement.
So gotta keep track of when finished streaming to network and
locally separately. That means the State needed to be more of a
bitflag and less of an enum.
Since the stereo option is computed from the .wav file, if you call
setOptions later (like the cow.js does), it resets stereo to false.
So, I now just copy the stereo flag into the new options, since the
sound file is the same.
Also, calling AudioClient::outputLocalInjector on the AudioClient
thread now to avoid potential concurrency issues accessing the
vector of injectors.
