[3.0.6] Stereo panning via onEditPostProcessVoiceDataEvent totally broken

[jaynus]

When performing stream manipulation with the onEditPostProcessVoiceDataEvent, the data does not seem to actually be used - it is just providing me with the stream data, but not utilizing my return of the stream.

Example:

The below works fine on the pre-processed stream it does perform my transformations.

ACRE_RESULT CTsEngine::onEditPlaybackVoiceDataEvent(uint64 server, ACRE_ID id, short* samples, int sampleCount, int channels) {
	//TRACE("[%d] - s:[%d],c:[%d]", id, sampleCount, channels);
	
	g_testRadioFilter.process(samples, sampleCount, channels);
	
	return ACRE_OK;
	
}

The following does nothing.

ACRE_RESULT CTsEngine::onEditPostProcessVoiceDataEvent(uint64 server, ACRE_ID id, short* samples, int sampleCount, int channels) {
	//TRACE("[%d] - s:[%d],c:[%d]", id, sampleCount, channels);
	
	g_testRadioFilter.process(samples, sampleCount, channels);
	
	return ACRE_OK;
	
}

Still transforms the provided stream - but it is not utilized for the actual audio output to TS3.

[nwerensteijn]

This bug has been fixed in the next release. Thank you for the report.

[jaynus]

Thanks! Will report back on next release.

[NouberNou]

This "fix" for stereo surround sound has totally broken any sort of ability for us to do this manually, using our own methods via the onEditPostProcessVoiceDataEvent. This was working fine with stereo sound data before 3.0.6 and now it seems like this API event does nothing to the audio.

Please fix this ASAP, as it is preventing a large portion of the Arma 2 community from updating to 3.0.6 due to the fact that it now breaks the ACRE plugin.

[NouberNou]

This looks like its been a bug before: http://forum.teamspeak.com/showthrea...am-is-not-used

Please address this quickly. It is seriously causing a major lack of confidence in the Arma community over the viability of Teamspeak as a stable platform for development of plugins.

[nwerensteijn]

I did a test but it seems to be working as expected, so right now I suspect you are using the api incorrectly. The only relevant change i can think of is that we defined 3 new speaker constants:

#define SPEAKER_HEADPHONES_LEFT         0x10000000
#define SPEAKER_HEADPHONES_RIGHT	0x20000000
#define SPEAKER_MONO                    0x40000000

This can cause code that is looking for SPEAKER_FRONT_(LEFT|RIGHT) to fail if teamspeak detects a headset/headphones or a mono output system.

If that is not it, please post/send me the relevant code, so I can see what is going on.

As an example here is my test routine. It is very very crude, please don't use it in real code. It just replaces the current voice output with a sine wave. It does not look at what channels are filled, or even verifies the clientID, so it sucks if more than 1 person speaks. Also, it only works if you connect less than 11 times per client startup

void ts3plugin_onEditPostProcessVoiceDataEvent(uint64 serverConnectionHandlerID, anyID clientID, short* samples, int sampleCount, int channels, const unsigned int* channelSpeakerArray, unsigned int* channelFillMask) {

	static int connections[]={0,0,0,0,0,0,0,0,0,0,0,0};
	int i,j;
	int period = connections[serverConnectionHandlerID];

	for(i=0; i < sampleCount; ++i){
		short sample = (0.5f*sin(120.0*2.0*3.1415f*period/48000.0))*32767;
		period = (period + 1) % 48000;
		for(j=0; j < channels; ++j){
			*samples++ = sample;
		}
	}
	connections[serverConnectionHandlerID] = period;
}

[NouberNou]

Actually it was that the signature for the function changed in the current SDK and I didn't see that. Added in the additional arguments and now its calling it (wasn't even firing before haha).

Sorry for the confusion.

[nwerensteijn]

No problem