View Full Version : No Sound When Too Many People In Channel
I'm presently experiencing an issue with a TS Server Running on Redhat Linux whereby when the number of people in a channel reaches 40 the last few people to enter the channel cannot hear anything said over TS. They can speak and we can understand them just fine, but they have can't hear anything short of the occasional blip every few minutes. The channel maximum is set to 60 and I've tried to bump this up even further. Also tried switching around CODECs. If I kick someone from the channel one of the previously affected people immediately gets their sound back. Also, If one of the affected people switches channels they are able to hear fine in the new (<40 people) channel. Bandwidth isn't an issue and the cpu/memory utilization seems fine.
I'm guessing that there is a setting somewhere or an internal limitation that I'm hitting.
I did the requisite reading on the forums and wasn't able to find a parallel to the situation that I'm experiencing. Any help would be greatly appreciated!
--Diode
If I remember right, this is not the first such post. However I must admit that I don't remember if there was a solution.
anyway, to my knowledge there is no "bug" known in TS which would cause such a behaviour.
- Are you really sure, bandwidth is no problem ?
- There is no OS limitation, limiting outgoing connections,... (if you have the chance to test the TS installation on a different server ?)
I'm in control of the network serving the machine and have verified that bandwidth utilization is far below what is available.
I was initially leaning toward some sort of OS limitation, but started moving away from that conclusion once I realized that I was experiencing this issue on a per channel basis (i.e. I can have >40 people connected and talking, just not in the same channel. From a connection perspective, is there anything that differentiates one channel from another (i.e. does every channel spawn its own child process, different range of udp ports, etc)? Any additional further assistance that you can provide is greatly appreciated.
--Diode
KingOfZeal
21-07-2006, 04:03
I'm in control of the network serving the machine and have verified that bandwidth utilization is far below what is available.
I was initially leaning toward some sort of OS limitation, but started moving away from that conclusion once I realized that I was experiencing this issue on a per channel basis (i.e. I can have >40 people connected and talking, just not in the same channel. From a connection perspective, is there anything that differentiates one channel from another (i.e. does every channel spawn its own child process, different range of udp ports, etc)? Any additional further assistance that you can provide is greatly appreciated.
--Diode
Lets see if I remember correctly when I ready about how the server works...
Sound from every source in a channel is sent to the server, where it's sent back out to everyone else in the channel. So, from a bandwidth perspective, it's (bandwidth from channel 1) + (Bandwidth from channel 2) ... (bandwidth from channel x). It's all sent on the same port to the various IPs. For more information on this, check this out: http://www.goteamspeak.com/index.php?page=faq&id=2&item=34#q34
Out of curiosity, how many would be talking at a time, and what codec are you using? If you're using a high-end codec (like Speex 25.9), try moving it down a little bit and see if that helps any. If it does, it may be something like a built-in cap on bandwidth.
Also, which type of server are you using? I'd really hate to be nosey like this, but if you're using the freeware version, you are supposed to have a limit of 100 people on a server: that may have something to do with it as well, though I couldn't tell you how.
Edit: techie things
After reading the like I made above, I have a feeling it DOES have something to do with how many people are talking at the same time. Now, while logic may say that no more then 1 person will be talking for a length of time in a single channel, and the server may be able to process that, any more then 2 or 3 streams (people talking) at the same time might be overtaxing the server, so a self-limitation is set up and blocks off people if can't serve.
Also, in regards to this, people don't have to be talking to send a voice stream: I know a few people in my own servers who don't have their mic calibrated exactly right, so a lot of time it sends dead air or keystrokes (because the voice sensitivity is set too low). I'm completly guilty of both at one point or another.
The number of people on the server itself doesn't seem to be a contributing factor. The TS server is used for a WoW guild, so when we're running 40 man raids there will generally be exactly 40 people in the channel. At most there may be 5 other people connected to the server on other channels. It seems that once we get above ~38 or so in the channel the last few people who join the channel will only hear an occasional blip of sound. I've watched the server while this is occuring and I'm not seeing more than one person key up at a time. If I drag them into an separate channel they can hear me just fine. If I kick someone else from the channel the previously affected person can hear just fine. I can say with certainty that the issue is not bandwidth related (the server is hanging off an ethernet segment on a rather large network). I have looked at the firewalls and there doesn't seem to be a limitation at that level either. I've even gone so far as to increase the number of FDs/process to see if this would impact the issue (it didn't). BTW, This is a CentOS/Redhat box.
Does anyone have knowledge of the innerworkings of the Teamspeak application who could speak to what resource pools are unique to each channel (other than the multiplicative bandwidth factor)? I'm an engineer... I can take it ;-)
--Diode
Lets see if I remember correctly when I ready about how the server works...
Sound from every source in a channel is sent to the server, where it's sent back out to everyone else in the channel. So, from a bandwidth perspective, it's (bandwidth from channel 1) + (Bandwidth from channel 2) ... (bandwidth from channel x). It's all sent on the same port to the various IPs. For more information on this, check this out: http://www.goteamspeak.com/index.php?page=faq&id=2&item=34#q34
Out of curiosity, how many would be talking at a time, and what codec are you using? If you're using a high-end codec (like Speex 25.9), try moving it down a little bit and see if that helps any. If it does, it may be something like a built-in cap on bandwidth.
Also, which type of server are you using? I'd really hate to be nosey like this, but if you're using the freeware version, you are supposed to have a limit of 100 people on a server: that may have something to do with it as well, though I couldn't tell you how.
Edit: techie things
After reading the like I made above, I have a feeling it DOES have something to do with how many people are talking at the same time. Now, while logic may say that no more then 1 person will be talking for a length of time in a single channel, and the server may be able to process that, any more then 2 or 3 streams (people talking) at the same time might be overtaxing the server, so a self-limitation is set up and blocks off people if can't serve.
Also, in regards to this, people don't have to be talking to send a voice stream: I know a few people in my own servers who don't have their mic calibrated exactly right, so a lot of time it sends dead air or keystrokes (because the voice sensitivity is set too low). I'm completly guilty of both at one point or another.
vBulletin® v3.7.3, Copyright ©2000-2008, Jelsoft Enterprises Ltd.