Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
We're getting real close to the 1.1 release, so I'd really appreciate it if those of you on the snapshot/SVN track would check out the current version and let me know if you find any bugs. I'm not interested in feature requests at this time, only bug reports and spelling corrections so we can get this release out the door.
If you don't find any bugs, I'd also appreciate a note saying that.
Some random points I care about:
Current SVN does not build on Mac OSX due to missing stubs for Overlay/Globalshortcuts. I will add a patch to the bugtracker after I have cleaned up my current checkout.
I need a Makefile in SVN in order to build a ready-to-install package for Max OS X. Do you mind adding a mac subdir with a Makefile in order to ease packaging (basically puts Qt into the application folder and adapts paths)? I'd submit a patch for this if it's wanted.
I'd like to create at least one snapshot for Mac OS X so people could test it before release
I have a patch for murmur on linux so one could build a (partially) static murmur that allows mysql-support and not only sqlite (couldn't get a fully static build working with mysql/postgresql libs)
I don't have a Mac, so I'm basically adding all the patches for Mac after making sure they don't interfere with the other platforms. So any patches you have will be applied. I'll even smile while doing so :)
The release schedule for 1.1.0 was yesterday. I'm waiting for the last bits of translation then it will be out the door, no later than midnight tonight. That being said, the next version will be 1.1.1 and will be out in a more timely fashion, so there will be time for more OSX things. If it's OK with you, we'll make OSX support one of the "selling points" of the 1.1.1 release?
I actually have a static murmur with mysql, as the static releases are built with a custom Qt that has fully static libraries. But if you have a patch which allows more easy building of static versions without recompiling Qt then I am definitely interested :) I think I'll still use the fully static build for the official releases (as they work on most 32 and 64 bit Linux distros), but many people have asked for an easier way to build static versions.
WIN32 Snapshot: mumble-2007-09-15_23-29
Just a small mistake, 20ms doesn't show as expected, it return the values to "TextLabel"
Which turned out to be a large fix; this wasn't the only place this problem could occur. It's been fixed now.
I can confirm this, but moving the slider does correct the problem, so you probably just forgot to initialize the string.
By the way, I wanna make a chinese translation for mumble 1.1. Hope the time of arrival can be reach as mumble 1.1 release.
I was testing the quality auto-adjust feature and found that even when the limit is set below the lowest possible client setting, it still connects and says auto-adjusted. Is it connecting regardless of its ability to lower the quality further or is it capable of lowering the quality lower than the config allows? Some more information about the current quality settings (specifically automatically overridden settings) would probably help avoid confusion relating to that; I think the Server Information would be a good place to put that. I'm not sure if you would consider that a feature request or not, but I'm mentioning it anyway.
Aside from that everything looks good so far.
There's a few other things I want to test but I need someone else to do it with, specifically Players above Channels and BF2 linking. I should have a friend coming on tonight who will help out and I'll let you know if I find anything.
By the way, I just noticed that "above" in "Players above Channels" should probably be capitalized.
Players above Channels seems to be working great now.
BF2 linking on the other hand seemed a bit unstable, but partially better than before. For me, it was the positional audio methods in general that were especially acting up. My Realtek HD integrated audio is supposed to be able to handle just about everything an average sound card does, it even supports 192kHz 32-bit audio on 8 channels and it rarely has problems with any other programs, so I think Mumble just needs to improve positional audio compatibility with some audio devices. I can't even use the panning method without this problem. The problem I'm having is that when I have positional audio enabled with any of the 3 methods, I can't hear anyone most of the time. Based on my tests, it seems that I need to join BF2 with the person I'm talking with in order to hear him with positional audio enabled, and only once during testing I was able to hear outside of the game with it enabled. My friend hasn't had problems with it, so I know it's got to be an issue with certain audio hardware. When I tried using my Sound Blaster Live! 5.1 card, all the audio (both BF2 and Mumble) went really screwy once I joined BF2; I'm not sure what was causing that and I think it was also happening when I had positional audio disabled.
The position of the voice audio seems to get "stuck" at times. Sometimes it works really good and I hear the direction changing instantly and sometimes I can turn 180 degrees and the voice is stuck on the wrong side for a few seconds, or sometimes it's centered when it's not supposed to be. This happened for both me and my friend. I'll probably be doing more testing on that to see if I can find any pattern as to what updates it and what doesn't.
It may support 7.1 audio. That is not the same as positional DirectSound audio. Many soundcard drivers are very buggy in their DirectSound3D implementations; buggy enough that
a) Most games do 3D positional audio in software and then present a pre-mixed stereo/5.1/7.1 signal to the audio card.
b) Microsoft removed the entire thing in Vista and basically told audio card makers; "Look, this was too complex for you. Here's a interface which simply takes a constant stream of data and outputs on your DAC. No computation. Think you can manage that?"
Now... Because of point a) above, audio card makers don't bother improving their DS3D implementation, since nobody uses them. Nobody uses them, because they're improperly implemented. And so the entire thing spirals into the current mess that is "Windows Audio Drivers". You should try some of the drivers that come with USB headsets; they'll bluescreen if you ask the driver if it supports DS3D.
I may end up doing a) myself. If I want positional audio for Linux and MacOSX, I'll have to. But unfortunately I won't have time to write (and test) a proper software mixer before 1.1 is out the door.
That reminds me, my friend who didn't have any problems uses a USB headset. Well, on second thought he did have a problem with an "audio crash" or something, but it only happened maybe twice while he was playing BF2 during the tests. It sounded like a crash he was familiar with.
What I don't understand is how the positional audio works fine when I least expect it to work (when I'm in the game) and it doesn't work when it's enabled but not even being used.
It will adjust it down as far as it can. Beyond this it will simply accept that the server quelches a few packets. Feel free to add a feature request to show how far down it's adjusted, but it won't make it until the 1.1.1 timeframe :)
The capitalization is standard article capitalization; capitalization of nouns and verbs. I'm not quite sure why I chose that style, but it seems consistent.
not really a software problem, but the readme.txt says "Murmur must be run from the command line". I never run it from the command line these days and aside from the popups telling me what ini file and what database it is using I don't have any problems with it. Nit-picky? Maybe, so I won't cry if you don't fix it.