View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001532 | FSSCP | sound | public | 2007-12-01 05:02 | 2007-12-01 12:54 |
| Reporter | havner | Assigned To | taylor | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | no change required | ||
| Product Version | 3.6.9 | ||||
| Summary | 0001532: LINUX: Minor sound distortions/statics. | ||||
| Description | They are very rare (generally playing), I've run on some major ones in one of fsport missions. The easiest way to get them is to just run afterburner (doesn't have to be fsport). They sound like some kind of statics. When you turn on afterburner you can hear them every second or so. Tested on HEAD, 3.6.9 release and 3.6.9 branch. Windows version (even run on Linux with WINE) doesn't have this. This can be connected somehow with ADPCM, cause i cant get this on BtRL data files, and they use mostly oggs (though there are some waves as well, didn't check in what format BtRL AB is in). | ||||
| Additional Information | And now why I think its bug in fs2_open not my system. First my sound specs: SB Live 51 (SB0060), emu10k1, alsa 1.0.14. In my Linux gaming history I've run on many such statics in games. Some of them were caused by dmix plugin (AC97 and HDA have no hw channel mixing). Those were fixed by using 'hw:0,0' instead of 'default' (the latter has dmix turned on by default) Others of them appeared on built-in cards: AC97 and HDA with conjuction with openal 0.0.8 which uses old ALSA api (0.9). This was a bug in either hda-intel drivers or alsa-lib 0.9 api implementation. The solution was to use SVN build of alsa (r1325 works pretty well, its already on new alsa api and still without changed ABI, though soname has changed). After I've changed sound card to sb live (which has VERY good alsa support in terms of such things) none of those problems ever appeared again. I fully realise that such bugs are in most cases cause by faulty drivers/dmix/wrong .openal/.asounrc settings etc. But please believe, I'm not a total rookie when it comes to setting alsa or openal under Linux and I'm almost certainly sure its not the case here. Especialy when windows version under wine has no such problems. This way we can eliminate driver/alsa-lib/alsa settings problems, only fs2_open and openal remains. I've tried stock openal 0.0.8, the one you provide in lib dir (i think its 0.0.8 as well) and the one I use on daily basis, SVN r1325 (i use it succesfully with commercial games on both hda and sblive). Those statics are reproducible on all of them. Changing default to hw:0,0 (the most compatible one) doesn't help as well. Please, just try to run Linux version (some training mission f.e.) wait for all other sounds to go away, volume up speakers a little and turn AB. You should hear about 2 statics every second. If it was only about them, then no problem. But there are few missions with louder music where I can hear it very loudly (f.e. when i move closer to some other ship engines) and it becomes very annoying. | ||||
| Tags | No tags attached. | ||||
|
|
Try adding "SoundSampleRate=44100" to the "[Default]" section of your ~/.fs2_open/fs2_open.ini file. If that doesn't work then you can try messing around with ~/.openalrc to try and work out the problem that way. See http://www.hard-light.net/forums/index.php/topic,50490.0.html for more info, and for continuing discussion on this. Either way, it's not a code bug and doesn't belong in Mantis. It's simply to data format and system config issues. |
|
|
Please, read Additional Info I've wrote carefully. I'm afraid this is not system issue (i've covered this in my description). This statics are not major and person with bad ear or bad speakers wont probably hear them. But they exist. SoundSampleRate=44100 didn't help. As playing with .openalrc cause I did it before reporting the bug. I've described everything there. And its not data format as well cause they dont exist on windows binary with exactly the same data (run on Linux with WINE as well as I've mentioned above). |
|
|
http://vega.livecd.pl/~havner/fso/windows.wav http://vega.livecd.pl/~havner/fso/linux.wav Please, listen to them. They were both recorded on the same system, on the same Linux, on the same settings. One is Linux version, the other is Windows run under WINE (WINE uses alsa + its settings as well). Please, bear with me. Run Linux version for a second and tell me if you got the same. I'm not talking about generally crackling sound like in the post you gave me. Most of such things are cause by built-in sound cards, I've covered it as well in Additional Info. Those seem to be statics for short waves that play repeatedly, like afterburners, engine sounds etc. |
|
|
I read all of the info just fine, but that doesn't change the fact that it is not a code issue on our side. The Windows and Linux code for sound playback is exactly the same, so if it happens on one but not the other then is almost zero chance that it's a game bug. It is almost certainly a system issue, which can also mean an OpenAL problem. The Linux version of OpenAL is still pretty far behind in comparison to the Windows version, so Windows simply may not exhibit the same bug for that reason. I'm not saying that the problem isn't there, just that it is not in our side of the code and therefore doesn't belong in Mantis. If you, or anyone else for that matter, can find a bug then we'll be quick to fix it and I will happily eat my words. Personally I would prefer to be proven wrong on this, since it's far easier to get things fixed when it's our fault rather than a system lib, but I just don't see the bug on our side. It is possible that there is yet another bug in the ADPCM decoded routines, but like I said, that code is used on Windows too. Plus the ADPCM decoder isn't from us, it's from an SDL lib, used with the permission of it's author (Ryan Gordon). So if there was a basic decoding problem then it would most likely be a known, and pretty broad, problem already. |
|
|
Still somehow other software based on linux openal has no such issues (I'm really sensitive about such statics in games). Its almost sure that this is caused by windows/linux openal differences but for sure it can be workarounded on fso side if others managed to do so. So lets just stop calling it a bug in fso. It may not be, I realize that Linux openal is far behind, 0.0.8 is from begining of 2006. And svn version above some point is unusable. "Personally I would prefer to be proven wrong on this, since it's far easier to get things fixed when it's our fault rather than a system lib, but I just don't see the bug on our side." Then cant you think of it as somehow that _can_ be workarounded on fso side? Can you at least please confirm you got this as well? |
|
|
Ok, found something more. Not all wavs in fs2 data are ADPCM. examples: 1. Input File : 'FS2_Arv_G02.wav' Sample Size : 16-bit (2 bytes) Sample Encoding: signed (2's complement) Channels : 2 Sample Rate : 22050 2. (this one is) Input File : 'FS2_Brief_01.wav' Sample Size : 16-bit (2 bytes) Sample Encoding: G72x-ADPCM Channels : 2 Sample Rate : 22050 3. (the problematic AB sound from sparky_fs2.vp) Input File : 'aburn_2.wav' Sample Size : 8-bit (1 byte) Sample Encoding: unsigned Channels : 1 Sample Rate : 22050 What are you using for playing such samples in windows and linux? Still the same code? Cause I've run into strange results. I've played 'aburn_2.wav' in few programs. Under windows in VPview it was ok. Under VPview/WINE there was _exactly_ the same result i get in game, static sound at the end of sample. Sox played this more or less fine (though there is something strange at the end, but not with that high pitch). Audacity and aplay (alsa one) played it 100% correct. Maybe problem is somewhere around here? All those programs didn't use openal and some of them didn't play it correctly. Please dont close this bug yet as even if its really not a problem with FSO code (I'm not implying it) maybe we'll be able to find some solution. |
|
|
I'm happy to work towards a solution, or at least to properly identifying the exact cause, but Mantis isn't the proper venue for such activity. Please move this discussion to the HLP forums, where everybody can assist, and we'll go from there. If there is found to be a FSO code bug (or even a simple workaround) then this bug can be reopened. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-12-01 05:02 | havner | New Issue | |
| 2007-12-01 07:08 | taylor | Note Added: 0008714 | |
| 2007-12-01 07:09 | taylor | Status | new => resolved |
| 2007-12-01 07:09 | taylor | Resolution | open => no change required |
| 2007-12-01 07:09 | taylor | Assigned To | => taylor |
| 2007-12-01 08:00 | havner | Status | resolved => feedback |
| 2007-12-01 08:00 | havner | Resolution | no change required => reopened |
| 2007-12-01 08:00 | havner | Note Added: 0008715 | |
| 2007-12-01 08:01 | havner | Note Edited: 0008715 | |
| 2007-12-01 08:09 | havner | Note Edited: 0008715 | |
| 2007-12-01 08:35 | havner | Note Added: 0008716 | |
| 2007-12-01 08:36 | havner | Note Edited: 0008716 | |
| 2007-12-01 08:40 | havner | Note Edited: 0008716 | |
| 2007-12-01 09:28 | taylor | Note Added: 0008717 | |
| 2007-12-01 09:32 | havner | Note Added: 0008718 | |
| 2007-12-01 09:35 | havner | Note Edited: 0008718 | |
| 2007-12-01 09:37 | havner | Note Edited: 0008718 | |
| 2007-12-01 10:24 | havner | Note Added: 0008719 | |
| 2007-12-01 12:54 | taylor | Note Added: 0008720 | |
| 2007-12-01 12:54 | taylor | Status | feedback => resolved |
| 2007-12-01 12:54 | taylor | Resolution | reopened => no change required |
