I've done a few more optimizations to the UDP part of murmur.
I've also made a small benchmark to test the worst-case scenario: All users in ONE channel. If you have a 100 clients, and one of them speaks, that means each packet has to be replicated 100 times and set out into the world again.
So, once I had this done, I tinkered a bit with the encryption. After all, it can't be that bad of a CPU hog? .. Well.. With the latest batch of optimizations to the server, adding encryption means the UDP thread spends 95% of it's execution time in AES_ofb128_encrypt. No, that's not a typo. So, naturally, encryption is out. .. Or...?
With encryption enabled, the server starts loosing packets at above 1300 clients. Without encryption, that limit is raised to 1500 clients. But doesn't this invalidate the benchmarking?
As it turns out, sending 75k UDP packets per second actually means the kernel and network drivers has to do something, and their work completely dominates the CPU time spent. So, yes, murmur spends 95% of the in-process cycles encryption, but overall, most of the work is spent outside the process. So encryption will be added when I find the time.
On a sidenote, I found a few other limits. For example, my testserver defaults to only 1024 open files/sockets per process. This was easily fixed. Qt uses select(), meaning it's limited at 1024 active sockets. That part required major hacking, and isn't likely to make it into Qt any time soon. Ah well, at least I've prooven Mumble scales to at least 1000 concurrent active users :)
(That is, providing they use the UDP mode. If they choose to do it all over SSL, the CPU crawls to a halt at ~160 users ;))