Posted 13 January 2013 - 07:20
Just found this sound bug thread thanks to demon!
If it helps, this is what I noticed, and some advice from the old timer of pre dot-com days.
I don't seem to have the bug as bad as some do, but it comes and goes on occasion.
from what I'm seeing, I feel there is a criss-cross in the software routines somewhere, like a shared variable or similar.
1) I run Regzooka and CCleaner when things go funny, and it seems to help to some extent. I flew almost all night on 1/11 without a sound issue. That was 4 hours, and I finally had a sound issue in the last 30 min of my night.
2) Flying a Gotha, I noticed:
once my sound suddenly cut out, I had minimal sounds. I'd hear some creaking of the plane and wind only.
I blipped the engines on/off a few times and it changed the fault. Sometimes, a tin can type sound. sometimes a constant motor sound, and most interesting, sometimes I'd get sound that was controlled by the throttle like a volume control Between 800rpm and 1250, I could hear the engines as normal, but, at 800, it was nice and loud, and by sliding to 1250, the sound went down like volume control. beyond 800 and lower, or 1250 and higher, the sound cut out all together for the engines. It would return in the rpm range noted.
3) from even the early days of the game, I noticed that when I went to a bomb sight in a German plane, ( I fly them the most) the engine (only)sound would always cut out. In some cases, the sound would cut out but as I moved the zoom control of the bomb sight it came back, the engine sounds would be affected like a volume control. I could hear other planes or guns firing. I never lost my sounds once returning to the cockpit until recently. Now it sometimes happens that I lose engine sound when I go to cockpit from bomb sight. And the volume control effect of the zoom control seems more prevalent now. Sometimes I go to bomb sight, and have a small sound, and as I zoom in, it gets louder, but I don't lose the sound.
4) flying a DFW, I noticed the similar affect. Also, with engine sound gone, also gun sounds were gone.
5) sometimes I only lose my own engine sound, and I can hear other planes or flak around me.
6) once, my teamspeak announced a 'user has timed out' message, and at the exact same moment, my sound went bad. I was on the Jasta 30 group under the ROF teamspeak site.
7) flying in a server, or quick mission mode, with optional views, I found that if I went from the cockpit view to external, I'd lose the sound. Sometimes I'd lose the sound, and by jumping back and forth from F1 to F2 (cockpit/external), my sound would return. Other view changes in quick mission could do the same.
Having been a manufacturing and electrical design engineer for many years, and having started on computers in the punch card days with Fortran, Basic, and then Turbo Pascal, I learned that the way I learned first was, and still is, the best way to program and troubleshoot. Do it on paper . I have solved issues using proper method of programming and review- doing it on paper.
I know the modern software guys can be a whiz, but hardly any of them are the true, hard core, professional-of-old that knows to keep track of things on paper, and once the originator moves on, the new guys can't hardly figure out what the last guy did, and you end up paying a bunch of money for tapitty-tap on the keys and 'let's try this' a bunch of times. The guy who will print out the code, at least the sections that pertain to the area of interest, and sit down at the big table with a pencil and all the paper, will have a higher degree of success.
Using logic, one can read the codes, understand the path, flow chart the program and 'bing', spot the problem, or at least be able to identify possible issues that don't appear to ring true to the desired result of the program. I'm not a degreed software engineer, and I was not familer with Unix, but I resolved a problem the major semiconductor company, that I worked for, had lived with for over 12 years until my boss asked me to look at it. Found 10 things wrong, and success was achieved. All I did was ask the software group to print out the section of code I needed, then I sat down and went through it, with a Unix book to understand the commands, for about a week and found the problems. And some of the problems were not simply a bad code in one spot- it was a string of commands that worked together in certain conditions and things went bad if certain parameters were met- and not totally bad, just intermittantly bad- which is worse. Not an easy spot for a key tapper, and well gee, they never did find the problems until I did the code on paper and showed it to them.
People who do not print, can't see the whole picture in place, nor jump around as fast in the code, and typically can't keep track of where they've been, nor track mulitple relations of routines in the code very well. They get lost, or miss things they skipped over. That leads to impatience and the desire to move on when the problem can't be solved quickly. Not hardly anyone listens to what I say about using the primal code methods, but I've had good results troubleshooting anything from hex code, to ladder logic type codes, to codes like Unix that I've never programmed with, and I worked it out every time.
My advice- find a very patient, programmer, or logical thinker type, then have him print and read vs tapiity-tap on the keys. You will find the problem if it's in the software. When laid to print, software loses all its magical mysteries.