This produces an integral number of samples when resampled to 44.1k or 48k, allowing a 44.1k back-end to work correctly without extra buffering or dynamic buffers sizes.
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...
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.
The initial HRTF reduced overall gain by -6dB to avoid clipping at spectral peaks. With the addition of a peak limiter, this is no longer necessary. Changing to 0dB improves the loudness match between spatialized and unspatialized sounds.
Adds a distance filter to model the frequency-dependent attenuation of sound propagation in open air.
Optimized using SIMD and computing all biquads in parallel. Performance impact is almost zero.
Filter updates are continuously interpolated and clean to -90dB.
Not enabled yet (distance hardcoded to 0.0f)
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.
Probably need to clean up a bit, but wanted to get this out there
for comment on more general issues, etc...
To test, I added a localOnly: true to the cow in the tutorial.
