TeamSpeak Sound Bug

[ShadowSwipe]

Greetings,
So currently working on a plugin that simulates radio mic clicks among other things in a more realistic fashion for TS. Now what we want to do is that we want new sounds to override other sounds when they start playing if the previous sound was still running. We have this "working" in a way, but our users keep experiencing unexpected crashing as a result. Originally we thought the issue was due to not pausing the sound handler before closing the handle, and that did alleviate the crashing issue for SOME users. However, for other users the problem persists. I can no longer recreate the crashing on my own system (x64 Windows) with neither x64 TS or x86 TS, but I know of at least one other x64 windows user who has still crashed out from the same issue. I'm not sure what we're doing wrong but any assistance is appreciated

I have included below three log files that show the critical error that is causing this (2 from an x86 user and one from an x64 user), as well as our own log file for our plugin, and below is a screenshot of the code snippet. It doesn't always crash out at the same point, sometimes it will do it quickly and some times it will take a bit.

Function:
https://gyazo.com/d2f41e3969d47bf20b807583e9291f03

In the logfile.txt you will notice a lot of spam, that is from our debug button, it attempts to run the function multiple times to recreate the crashing issue.

The following is the ciritical error from the TS log files:
2019-04-02 20:20:44.522541|CRITICAL|GenericSoundChannel| |Assertion "(m_FillSimpleCallback) || (m_FillComplexCallback)" failed at c:\jenkins\workspace\client\clientwindows\deps\tea mspeak_client_lib\src\sound\genericsoundchannel.cp p:215;

[thorwe]

Eliminating the possibility for that critical to happen is on my list, but will take some serious changes, time and testing.
Meanwhile, if you point me to or send me the source, I can have a look. Should be avoidable to provoke it in the first place.

[ShadowSwipe]

Eliminating the possibility for that critical to happen is on my list, but will take some serious changes, time and testing.
Meanwhile, if you point me to or send me the source, I can have a look. Should be avoidable to provoke it in the first place.

Alrighty. We are still doing some testing but it looks like by adding a 25 ms buffer from the function being called too quickly in succession we have eliminated the issue.

New function: https://gyazo.com/e264f2496b9002f3e92056b9e113a82b

[ShadowSwipe]

Eliminating the possibility for that critical to happen is on my list, but will take some serious changes, time and testing.
Meanwhile, if you point me to or send me the source, I can have a look. Should be avoidable to provoke it in the first place.

Okay so the problem still exists, although the 25ms buffer has definitely helped a lot, some users are still experiencing some crashing.

The following functions are the two functions where the sounds are played from where it eventually crashes out, for reference.
https://gyazo.com/fcbf2e2d7dd708a8c5ec7596393b8036
https://gyazo.com/4fef2a1757ec9ea541076610e8c17f59

[ShadowSwipe]

Eliminating the possibility for that critical to happen is on my list, but will take some serious changes, time and testing.
Meanwhile, if you point me to or send me the source, I can have a look. Should be avoidable to provoke it in the first place.

So is there any idea what exactly causes this critical, we still aren't precisely sure. Is it really two sounds playing at once or something else. Any ideas?

[thorwe]

Sorry for the delay.

Right now the best bet to avoid this consists of basically two things in audio callbacks (any callback involving audio buffers, e.g. onEditCapture..., plus onTalkStatusChangedEvent).

1) Avoid using ts3_functions in there, if possible. There can be threading issues.

2) Try to apply as many recommendations for audio code as possible ( for an overview: http://www.rossbencina.com/code/real...ts-for-nothing ).
E.g. busy waiting, as I've seen on another github project, ain't healthy in those callbacks.

That's all I can say for now without further investigation into the critical and/or more than screenshots of code snippets.