Is 16,4 GSM the best codec?

[Sankan]

I want a better codec!
Were can i find it?

[Peter]

or better, in the future

[Sankan]

Isn't there a better codec then?

[guldi]

what for do you want a better codec then the GSM ?
This codec offers VERY good quali !
TS has been invented for use over the WAN. The GSM is taking a lot of bandwith, often TOO much for the WAN.
So this one is more or less done for LAN or very powerful connections.

[Renegat3]

Originally posted by guldi
The GSM is taking a lot of bandwith, often TOO much for the WAN.
So this one is more or less done for LAN or very powerful connections. Hi!

I wouldn't say that! The WAN is fast enough for that (unless you're talking about the WAN connection)!
The Problem is TCP itself. TCP devides the Data in packages and sends them. So the target has to put
them together again. So sometimes it has to wait for the packages. This is caused by different reasons.
For every send package you (should) recieve an acknowledge package (ACK), only than the next package
will be send. If you don't recieve an ACK, for a default time, the package will be send again.
And/Or you catch a busy router. AFAIK the packages aren't necessarily going through the same route.
This all means you have lags in your TCP stream! Which is not a problem for your "normal" data (actually
you don't even notice it), but audio streams result in cutted out sound!

Puh,... not easy to explain in english!

regs
R3

PS: I hope I didn't tell something you already know ;)

[Judas]

Originally posted by Renegat3
Puh,... not easy to explain in english!

Too bad that it doesn't have anything to do with Teamspeak though ;)

Teamspeak doesnt only depend on UDP for the voicestreams and since TS2 doesnt even use TCP for establishing connections. What you said about TCP is perfectly correct though (at least as far as i know). But UDP is a connection less protocol. So to say (now is me walking on thin ice) Data just gets sent, taking whatever route it likes and there is no way of telling if the stream has been complete nor not. Yet thats exactly what you want for real time applications like online Games or Teamspeak.

Anyways... There is a second problem involved in codecs which use a lot of bandwidth (lets say 5 or even 10kb/s) on a WAN. Teamspeak is a client/server software. If traffic sent gets multiplied by the server and if you have 8 people in one channel with just 1 talking you already have 70KB/s outgoing traffic on the server (assuming that a 10KB/s codec was used.) In the very rare case of everyone talking or echoing back the server will have 560KB/s outgoing traffic.
Now even that ammount can be handled with a decent enough line but the clients (incoming traffic would be 70KB/s, assuming that everyone is talking) will most probably start to have problems.

But thats just numbers, it really all depends on what connections you and your people got and what kind of bandwith the server has. I just wanted to point out the effect of bandwith intensive codecs.

I agree that they are nice to have on a LAN where you really dont care all that much about another 500KB/s. Yet there is no imminent need and I think that we will get them codecs when the more pressing problems have been solved.

[Renegat3]

Originally posted by Judas


Too bad that it doesn't have anything to do with Teamspeak though ;)


Damn right, my mistake! I forgot about UDP! somehow I was sticked to TCP.
Anyway, UDP is also based on packages! So, there's the same problem. But actually it's better to loose a package then to wait intirely for a ACK!

But thats just numbers, it really all depends on what connections you and your people got and what kind of bandwith the server has. I just wanted to point out the effect of bandwith intensive codecs.

FULL ACK! That's why I was talking about the WAN itself and not the WAN-connection!
I just red about a guy, who has a server on a 4Gb Backbone with over 300 users logged!

Thanks for correcting me...!

Greets
R3

[guldi]

nice disscussion guys !

But I REALLY was talking about the WAN access (connection). This is usually the Problem when using high codecs.
Serious: who has a 4GB backbone in hand ?

[Genom]

But is it really necesary? I just started using teamspeak last night but the default lowest bitrate codec sounded great! A buddy hosted the server on his colocated machine, while I hosted a Raven Shield game on my DSL with 8 players and nobody lagged at all. One of the guys has 144Kbit IDSL and he was running great with the rest of us. And like I said, sound quality was amazing. Everybody's voice was easy to recognize.

[SatanClaus]

ok, sometimes, especially if there are like 2 or 3 people talking at the same time, you can't understand anything when using a "low" codec and most times you can guess what was said when using GSM...

but normally the people who want a "better" codec are those, who want to play music by using TS... And that's just sort of the opposite of what TS was designed for.

So I don't think that there's a strong desire for a better codec if you still want to play games at the same time :)

cu
SatanClaus