After 11th user joins no clients can hear

[paurience]

I have recently setup a TeamSpeak server for our WoW clan. Up to 10 users can join and everything seems to work fine. When the 11th user joins all of the users can no longer hear. They are reporting that they can still talk, by which I am assuming that they mean they are seeing the icon change collor when they speak. Unfortunatly I was not there when the issue appeared. I currently have a cable modem through Comcast. Speedtests at broadbandreports.com indicate speeds of 3400Kb down and 341Kb up. Any ideas why the clients would stop receiving sound after the 10th client joins? For input directly from the users see the clan forum at http://www.invisiblefork.com/ar/arboard/viewthread.php?tid=606&page=1#pid4174

Codec: Speex16.4
TeamSpeak version: 2.0.20.1
OS: Windows Server 2003 /w SP1
Sound card: None
Game: No game running on server, but clients are all wunning World of Warcraft
DirectX Version: DirectX 9.0c (4.09.0000.0904)
What error message do you receive? No errors logged
How often does the error appear? Only have had sufficient traffic one night
What did you do to resolve the problem? No resolution (Attempting to resolve issue by lowering codec to Speex3.4)
and last but not least: Are you a hot looking girl? No.

[(ETS) david]

I assume that your also playing on the same computer? if so then your out of bandwidth, you have to remember that home broadband is contended so your not always going to get the max speed the line can handle and this is doubley so at peak times, your better of using a cheap TS provider like us <removed URL> because if your serious about gaming then the small cost will ensure that your available bandiwth for gaming is there.

Edit by Peter: please, less of the advertising. If necessary, point to the ATHP list, instead of individual ones from it. List is: http://sales.tritoncia.com/hosters.php

[paurience]

I am not playing on the server running teamspeak, but I think that your response was more with regards to bandwidth instead of system resources. No bandwidth was being utilized by any internal users on my network at the time. We were out of town when the testing took place.

So basically it's a bandwidth issue. I find that odd since there were no reports of choppiness prior to the loss of hearing. I am also persuing the possibilty that it is an issue with a piece of network equipment on my network. It turns out after some additional research that I have a 10Mb-Half duplex router in place. I will upgrade that and see if that helps with some of my issues. Thanks for the input. If that resolves my issue I will post back.

[guldi]

a bandwidth issue would be usually indicated by lag and chopiness, but total loss of the capability to hear :confused: hmmm...
what codec is selected in the channel and were more then one speaking at the same time ? IS that problem repeatable ?

You might want to check the bandwidth FAQ (see link in my signature) for a background how you can calculate the requirements. 341kkb sounds nice, but remember that already 11 people in one channel where one speaks require an upload of 259kb (with the highest codec selected). If two speak at the same time, your bandwidth is already too small !!!

[(ETS) david]

Remember that inbound TCP packets require outbound acks so this is why I thought that he might be playing at the same time

[Peter]

Hi there,

though bandwidth on your line can be busted with 10+ people and multiple of them talking at once, I don't think this is the issue at hand, if you describe it correctly. Because having even 30 people join does NOT take alot of bandwidth, as long as they don't start to talk. Even if you were 30 guys, as long as only _one_ talked, it *should* work out fine (maybe choppiness, but not total silence). Something is going wrong here and it is very hard to put a finger on anything specific, you will have to do the good old trial-and-error way (change provider, router, server pc and test test test) to find more information to go at.
Some information for you: There _has_ to be some data flow between the clients 11 and further, because elsewise they would timeout (and they couldn't connect, in the first place), so it is not like the whole client<->server connection (for clients 11, 12, ...) is dead, if what you say is correct it is only the voice data that is not being delivered to these clients... I have no ready answer for the problem, report in with fresh data from the trial-and-erroring.

[paurience]

I did find out another interesting piece of trivia about the firewall I had in place (which I have since replaced, but we have not had opertunity to test). It apparently is only capable of supporting 10 outbound connections. I don't know if this is the problem, though it is hard to think that the number 10 is just a coincidence. It should be 10 clients, not 10 outbound connections total.

The original codes was the default Speex16.3 I setup a spreadsheet to calculate the maximum number of participants and the maximum number of people who can talk and found out that a 20 person RAID is not going to fly on Speex16.3. I currently have it set to Speex 3.4 just so we can test and make sure it's bandwidth and not some configuration issue. By my calculations, if I am not playing, then the upstream bandwidth I have should be able to support 4, maybe even 5 users talking concurrently. The test is going to be if the quality is good enough.

Thank you all for your input so far.

[(ETS) david]

That sounds like it have a bearing on it but it would only stop the 11th player and so on, your better off doing what you are and doing some testing