2020-04-06 04:21 EDT


View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002266FSSCPsoundpublic2012-08-16 01:19
Reporterchief1983 
Assigned Toiss_mneur 
PrioritynormalSeveritymajorReproducibilityrandom
StatusresolvedResolutionopen 
Product Version3.6.13 
Target Version3.6.14Fixed in Version 
Summary0002266: In new OpenAL code, dense soundscapes cause sounds to intermittently not play.
DescriptionI have heard from both Diaspora and FotG developers of instances in which sounds will not play during intense action and lots of sounds. Shade mentioned that flak sounds were not audible periodically when right next to the source, and zookeeper mentioned that his own primaries failed to make sounds when testing some FotG capital ships.
TagsNo tags attached.
Attached Files
  • log file icon fs2_open.osx.3614rc6.log (9,280 bytes) 2012-05-27 12:04
  • log file icon fs2_open.osx.openalsoft.log (8,359 bytes) 2012-05-27 12:05
  • ? file icon Mantis_2266.fs2 (10,121 bytes) 2012-06-28 00:17
  • patch file icon mantis2266-channel-detection.patch (1,073 bytes) 2012-07-04 07:52 -
    Index: code/sound/openal.cpp
    ===================================================================
    --- code/sound/openal.cpp    (revision 8970)
    +++ code/sound/openal.cpp    (working copy)
    @@ -197,19 +197,21 @@ static void find_playback_device()
     		// check how many sources we can create
     		static const int MIN_SOURCES = 48;	// MAX_CHANNELS + 16 spare
     		int si = 0;
    +		ALuint source_id[MIN_SOURCES] = {0};
     
    -		for (si = 0; si < MIN_SOURCES; si++) {
    -			ALuint source_id = 0;
    -			alGenSources(1, &source_id);
    +		for (si = 1; si <= MIN_SOURCES; si++) {
    +			alGenSources(si, &source_id[0]);
     
    -			if (alGetError() != AL_NO_ERROR) {
    +			const char *error_text = openal_error_string(0);
    +			if ( error_text != NULL ) {
    +				mprintf(("OpenAL error \"%s\" when creating %i sources with device: %s\n",error_text,si,pdev->device_name.c_str()));
     				break;
     			}
     
    -			alDeleteSources(1, &source_id);
    +			alDeleteSources(si, &source_id[0]);
     		}
     
    -		if (si == MIN_SOURCES) {
    +		if (si == MIN_SOURCES+1) {
     			// ok, it supports our minimum requirements
     			pdev->usable = true;
     
    
    patch file icon mantis2266-channel-detection.patch (1,073 bytes) 2012-07-04 07:52 +
  • patch file icon mantis_2266_fix.take3.patch (3,504 bytes) 2012-07-04 22:09 -
    Actually do as the comment says and don't play the sound
    
    Our fancy OpenAL implemenation needs to be as harsh to the engine as
    the original sound code and just deny the request just like the old
    sound code implemenation would.  Otherwise all of the fine tuning that
    :v: did is thrown out and the engine just trips over itself.
    Index: code/sound/ds.cpp
    ===================================================================
    --- code/sound/ds.cpp	(revision 8846)
    +++ code/sound/ds.cpp	(working copy)
    @@ -1408,34 +1408,37 @@
     		}
     	}
     
    -	// Make sure that we are not going to play more copies of this sound than we should be
    -	if ( Cmdline_enforce_concurrent_sound_count && (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) {
    +	// If we've exceeded the limit, then maybe stop the duplicate if it is lower volume
    +	if ( (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) {
     		// If there is a lower volume duplicate, stop it.... otherwise, don't play the sound
     		if (lowest_instance_vol <= new_volume) {
     			ds_close_channel_fast(lowest_instance_vol_index);
     			first_free_channel = lowest_instance_vol_index;
    +		} else {
    +			// NOTE: yes we are preventing the sound from playing even if
    +			// there is an available channel because we are over the limit
    +			// requested by the rest of the engine, which means if we do
    +			// not honour its request to limit the count then the engine
    +			// will trip itself up by using all channels without having
    +			// the intention of actually doing so.  This means we get
    +			// very loud sounds, missing more important sounds, etc.
    +			// Effectivly the problem is the rest of the engine assumes
    +			// it is still stuck in the 90s with a sound card that only has
    +			// <=16 channels so we need to give it a sound card that
    +			// has 16 channels (though we are actually allowing 32 channels
    +			// just because we can).
    +			first_free_channel = -1;
     		}
    -	}
    -
    -	if (first_free_channel < 0) {
    -		// If we've exceeded the limit, then maybe stop the duplicate if it is lower volume
    -		if ( (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) {
    -			// If there is a lower volume duplicate, stop it.... otherwise, don't play the sound
    -			if (lowest_instance_vol <= new_volume) {
    -				ds_close_channel_fast(lowest_instance_vol_index);
    -				first_free_channel = lowest_instance_vol_index;
    +	} else {
    +		// there is no limit barrier to play the sound, so see if we've ran out of channels
    +		// stop the lowest volume instance to play our sound if priority demands it
    +		if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) {
    +			// Check if the lowest volume playing is less than the volume of the requested sound.
    +			// If so, then we are going to trash the lowest volume sound.
    +			if ( Channels[lowest_vol_index].vol <= new_volume ) {
    +				ds_close_channel_fast(lowest_vol_index);
    +				first_free_channel = lowest_vol_index;
     			}
    -		} else {
    -			// there is no limit barrier to play the sound, so see if we've ran out of channels
    -			// stop the lowest volume instance to play our sound if priority demands it
    -			if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) {
    -				// Check if the lowest volume playing is less than the volume of the requested sound.
    -				// If so, then we are going to trash the lowest volume sound.
    -				if ( Channels[lowest_vol_index].vol <= new_volume ) {
    -					ds_close_channel_fast(lowest_vol_index);
    -					first_free_channel = lowest_vol_index;
    -				}
    -			}
     		}
     	}
     
    
    patch file icon mantis_2266_fix.take3.patch (3,504 bytes) 2012-07-04 22:09 +
  • patch file icon mantis_2266_fix.take3.trunk.patch (2,947 bytes) 2012-07-04 23:34 -
    Index: code/sound/ds.cpp
    ===================================================================
    --- code/sound/ds.cpp	(revision 8916)
    +++ code/sound/ds.cpp	(working copy)
    @@ -1402,24 +1402,36 @@
     		}
     	}
     
    -	if (first_free_channel < 0) {
    -		// If we've exceeded the limit, then maybe stop the duplicate if it is lower volume
    -		if ( (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) {
    -			// If there is a lower volume duplicate, stop it.... otherwise, don't play the sound
    -			if (lowest_instance_vol <= new_volume) {
    -				ds_close_channel_fast(lowest_instance_vol_index);
    -				first_free_channel = lowest_instance_vol_index;
    -			}
    +	// If we've exceeded the limit, then maybe stop the duplicate if it is lower volume
    +	if ( (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) {
    +		// If there is a lower volume duplicate, stop it.... otherwise, don't play the sound
    +		if (lowest_instance_vol <= new_volume) {
    +			ds_close_channel_fast(lowest_instance_vol_index);
    +			first_free_channel = lowest_instance_vol_index;
     		} else {
    -			// there is no limit barrier to play the sound, so see if we've ran out of channels
    -			// stop the lowest volume instance to play our sound if priority demands it
    -			if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) {
    -				// Check if the lowest volume playing is less than the volume of the requested sound.
    -				// If so, then we are going to trash the lowest volume sound.
    -				if ( Channels[lowest_vol_index].vol <= new_volume ) {
    -					ds_close_channel_fast(lowest_vol_index);
    -					first_free_channel = lowest_vol_index;
    -				}
    +			// NOTE: yes we are preventing the sound from playing even if
    +			// there is an available channel because we are over the limit
    +			// requested by the rest of the engine, which means if we do
    +			// not honour its request to limit the count then the engine
    +			// will trip itself up by using all channels without having
    +			// the intention of actually doing so.  This means we get
    +			// very loud sounds, missing more important sounds, etc.
    +			// Effectivly the problem is the rest of the engine assumes
    +			// it is still stuck in the 90s with a sound card that only has
    +			// <=16 channels so we need to give it a sound card that
    +			// has 16 channels (though we are actually allowing 32 channels
    +			// just because we can).
    +			first_free_channel = -1;
    +		}
    +	} else {
    +		// there is no limit barrier to play the sound, so see if we've ran out of channels
    +		// stop the lowest volume instance to play our sound if priority demands it
    +		if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) {
    +			// Check if the lowest volume playing is less than the volume of the requested sound.
    +			// If so, then we are going to trash the lowest volume sound.
    +			if ( Channels[lowest_vol_index].vol <= new_volume ) {
    +				ds_close_channel_fast(lowest_vol_index);
    +				first_free_channel = lowest_vol_index;
     			}
     		}
     	}
    
    patch file icon mantis_2266_fix.take3.trunk.patch (2,947 bytes) 2012-07-04 23:34 +
  • patch file icon mantis_2266_take3_followup.patch (1,203 bytes) 2012-07-31 01:23 -
    Index: code/sound/ds.cpp
    ===================================================================
    --- code/sound/ds.cpp	(revision 9076)
    +++ code/sound/ds.cpp	(working copy)
    @@ -1401,6 +1401,8 @@
     					lowest_instance_vol = chp->vol;
     					lowest_instance_vol_index = i;
     				}
    +			} else if ( chp->is_voice_msg ) {
    +				// a playing voice message is not allowed to be preempted
     			} else if ( (chp->vol < lowest_vol) && (chp->looping == FALSE) ) {
     				lowest_vol_index = i;
     				lowest_vol = chp->vol;
    @@ -1429,9 +1431,10 @@
     			// just because we can).
     			first_free_channel = -1;
     		}
    -	} else {
    -		// there is no limit barrier to play the sound, so see if we've ran out of channels
    -		// stop the lowest volume instance to play our sound if priority demands it
    +	} else if (first_free_channel == -1) {
    +		// there is no limit barrier to play the sound, but we have run out
    +		// of channels so stop the lowest volume instance to play our sound
    +		// if priority demands it
     		if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) {
     			// Check if the lowest volume playing is less than the volume of the requested sound.
     			// If so, then we are going to trash the lowest volume sound.
    
    patch file icon mantis_2266_take3_followup.patch (1,203 bytes) 2012-07-31 01:23 +

-Relationships
related to 0002680assignediss_mneur FSO does not correctly detect a sound card that does not support MIN_SOURCES 
+Relationships

-Notes

~0012246

Renegade Paladin (reporter)

Last edited: 2010-07-19 15:37

I have this problem on 3.6.12 RC3. (Not sure why 3.6.13 is a reporting option if 3.6.12 isn't even technically released yet, but whatever.) The bug affects game sounds of all types (primary sounds, missile launches, capital ship weapons fire of all varieties, afterburners, and even voice acting lines). This happens across all mods since I moved from RC2 to RC3, and is not specific to any given one. Sometimes when a VA line doesn't play it just produces silence and sometimes Microsoft Sam will take over the line. Occasionally the line won't start at the beginning, but the voice will cut in halfway through it.

~0012247

chief1983 (administrator)

RP, it's because there are now nightly builds released that have the fresh new OpenAL code, and if people are reporting bugs in that code they need a proper option. Trunk builds are currently tagged as 3.6.13 as they're development builds for the next stable release after 3.6.12.

~0013570

iss_mneur (developer)

Please attempt to reproduce this bug with OpenALSoft and/or -no_3d_sound flag enabled so that we can rule out this being caused by sound hardware that is lying or unable to handle the number of concurrent sounds required.

~0013584

chief1983 (administrator)

Even if it is because there are too many sounds required, shouldn't there be a stacking based on relevance, such that sounds emitting from the player's ship, or very nearby it, or very loud sounds would take precedence? And I will admit, OpenAL soft does fix a lot of the issues, but I can't figure out how to use it on my Mac. Having to turn off 3d sound altogether to get any decent sound is kind of annoying. I'm open to suggestions on how to use OpenAL Soft on OS X.

~0013586

iss_mneur (developer)

That's the thing. FSO already does that and for most people it seems to work just fine.

The problem appears to be that the number of sounds that the sound card can actually process at one time appears to be smaller than the number that FSO thinks the sound card has (which IIRC is queried by FSO when it starts up) this results in the sounds just disappearing when FSO starts using audio channels that the sound card can't use/doesn't have.

As far as OpenAL Soft for OS X goes. According to [1] you simply need to download and build the source available from [2] and make it available. Unfortunately I do not have a Mac to test this with.

[1] http://code.google.com/p/naev/issues/detail?id=131
[2] http://kcat.strangesoft.net/openal.html

~0013587

chief1983 (administrator)

I have built OpenAL Soft, but I can't figure out if it's supposed to work like a drop in replacement somehow like on Windows, or if you have to build the app against it, as it seems the NAEV link above suggests doing. Nothing I have much time to fiddle with right now at least, unless I somehow find myself bored at work again.

~0013613

jg18 (developer)

Last edited: 2012-05-27 10:03

View 3 revisions

From OpenAL Soft's CMakeLists.txt, it looks like you can build a static library by passing -DLIBTYPE=STATIC when you run CMake; that is, the command becomes "cmake -DLIBTYPE=STATIC .." . I've tried this and after running make, a static library (libopenal.a) is generated instead of a .dylib, along with two executables, makehrtf and openal-info. Hope this helps.

~0013614

jg18 (developer)

Last edited: 2012-05-27 10:25

View 2 revisions

Replying to what chief1983 said, my impression is that there's no (straightforward) way to build an OS X Framework from the OpenAL Soft tarball, so we'd probably have to build FSO against the OpenAL Soft library.

~0013615

jg18 (developer)

Update: after some tinkering with FSO's Xcode 3 project to use libopenal.a instead of OpenAL.framework and also adding -DCMAKE_C_FLAGS=-m32 when running CMake with OpenAL Soft (to force the generated code to be i386 instead of the native x86_64), I now have an FSO build that uses OpenAL Soft instead of Apple's OpenAL, as confirmed in a debug log (see attached logs).

It's currently just tied to my local copy of libopenal.a and also it's just i386 with the 10.7 SDK, since I couldn't get the OpenAL Soft build system to use an earlier SDK, let alone generate a PPC build (might not be possible on Lion, even with Xcode 3, dunno). It's a start, though.

One odd thing about the build is that when you run it, neither the Dock nor OS X's top menu bar disappears. Not sure how to fix that. Sound plays fine, though. I played partway through a retail mission ("A Lion At The Door") without mods and didn't run into any problems other than the ones mentioned.

~0013659

iss_mneur (developer)

Try the below link for an RC6 build using OpenAL Soft.

I don't notice any degradation, but I haven't tested it to strenuously.

https://www.box.com/s/fa9e3d8a1696879ec436

~0013696

MjnMixael (manager)

Played with this for a while today and didn't notice any issues.

~0013732

iss_mneur (developer)

I have added a mission to this ticket that provides a dense soundscape that exhibits this bug.

I have also tested different builds with this mission and ... I dunno.

With the OpenALSoft build, there is a loud drone that builds as I approach the ships and it fades as I fly away. With the number of sounds that the test mission puts out there, the player gun occasionally makes a sound (where as with trunk the player weapon never makes a sound when you fly though). This drone does not happen with the regular RC6 build, though I am not sure if this is intentional or not. The drone sounds like 100's of guns firing (and it reinforces the danger of flying between two Orions and 4 Aeolus.

Can someone confirm or deny these findings?

~0013733

niffiwan (developer)

Last edited: 2012-06-30 05:59

View 2 revisions

I know I'm running Linux, which is a bit different, but I thought it might be useful to add what my testing has shown.

Firstly, I think that Linux always uses OpenAL Soft, i.e. from fs2_open.log

Initializing OpenAL...
  OpenAL Vendor : OpenAL Community
  OpenAL Renderer : OpenAL Soft
  OpenAL Version : 1.1 ALSOFT 1.13

Also, there's an oalsoft-conf utility available, which I've used to set the playback device to "PulseAudio" rather than the default of "ALSA" - doing this stopped a lot of warning messages (from OpenALSoft) appearing when running fs2_open.

As for testing with the provided mission:

1) there doesn't appear to be any different between trunk & 3.6.14 RC6
2) without -no_3d_sound a lot of sound gets lost. Even without firing primaries many of the flak bursts do not play, and those that do play seem truncated.
3) with -no_3d_sound fewer sounds get lost. The flak is much clearer all the time, although when you're in the densest part of the flak bath the Subach firing sound plays intermittently.

All this is playing on headphones via my SB Audigy, I've got an onboard Nvidia device as well that I'm going to work out how to enable and run some tests with (as well as that GF106 device - whatever that is... I don't have headphones with a HDMI plug though!)

Lastly, I've also been experimenting with changing the selected playback/capture devices however none of the different choices have made any difference. FYI - my available choices currently are as follows (as reported in fs2_open.log)

  Available Playback Devices:
    GF106 High Definition Audio Controller Digital Stereo (HDMI) via PulseAudio *preferred*
    ALSA Default *default*
    HDA NVidia [HDMI 0] (hw:0,3) via ALSA
    HDA NVidia [HDMI 0] (hw:0,7) via ALSA
    HDA NVidia [HDMI 0] (hw:0,8) via ALSA
    HDA NVidia [HDMI 0] (hw:0,9) via ALSA
    SB Audigy 1 [SB0090] [ADC Capture/Standard PCM Playback] (hw:1,0) via ALSA
    SB Audigy 1 [SB0090] [Multichannel Capture/PT Playback] (hw:1,2) via ALSA
    SB Audigy 1 [SB0090] [Multichannel Playback] (hw:1,3) via ALSA
    PulseAudio Default
    SB Audigy Analogue Stereo via PulseAudio

Edit: removed comments re: wxlauncher - I was running an older version

~0013755

niffiwan (developer)

I've done some more testing with my onboard sound card, a "Realtek ALC892". OS says:

00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA)

(oops - I was wrong when I said Nvidia device above...)

Anyway - with the following device (Built-in Audio Analogue Stereo via PulseAudio) selected in wxlauncher I get the following:

1) without -no_3d_sound - I get a crackling/popping when loud sounds play like beams / flak bursts. Primaries stop playing intermittently in the middle of the flak
2) with -no_3d_sound - pretty much the same as 1)

When I switch wxlauncher over to this device (HDA ATI SB [ALC892 Analog] (hw:0,0) via ALSA), my results are pretty much the same as for when using my SB Audigy as per my previous post (points 2 & 3)

Both these results are using 3.6.14 RC6.

~0013792

niffiwan (developer)

Errr.. maybe this is silly, but I bumped MAX_CHANNELS to 256 to match my default configuration of OpenAL Soft, and voila, no more sound-not-playing issues.

Do any Windows OpenAL-Soft users have the following config file available?
%AppData%\alsoft.ini

If so - is there a line like the following, and what is its value?
sources = 256

~0013817

jg18 (developer)

Last edited: 2012-07-04 03:43

View 2 revisions

Here's what I have so far using the test mission:

3.6.14 RC6 using Apple's OpenAL and my version of trunk with OpenAL Soft sound about the same on the test mission. While continuously firing the Subach, there's maybe a few gun sounds while in/near the ring, but it's mostly silent gunfire in that area. I haven't checked the flak or beam sounds, and TBH I'm not entirely sure I remember what flak is supposed to sound like.

As for niffiwan's last comment, I found the alsoftrc.sample config file in the OAL Soft source tarball and copied it to my home dir as described in the file, using "sources = 256". I tried bumping MAX_CHANNELS in the code to 256, but then I got that drone sound that iss_mneur described. I then tried adjusting MIN_SAMPLES to 272 (or 256+16, since the original value of MIN_SAMPLES was a hardcoded version of MAX_CHANNELS+16) and still got the droning sound, so loud in both cases that I couldn't hear whether the gunfire sound was playing.

More importantly, FSO hangs and then eventually CTDs (wxL says it returned -1) whenever I try to exit this mission or jump out. I can produce a debug log and attach it to the ticket if you want.

Just would like to add that I'd especially like to hear from chief or E9 on whether their test results are similar to mine and whether they can reproduce the hang+CTD.

~0013818

niffiwan (developer)

I've been trying to reproduce the drone noise but I can't manage it so far. I've tried using OpenAL Soft 1.14 as a dynamic lib and as a static lib (with & without MAX_CHANNELS 256) - it doesn't seem to make any difference from 1.13 (except for some messages like this "AL lib: alcOpenDevice: Option 'format' is deprecated, please use 'channels' and 'sample-type'").

I recorded a sample of me playing the mission through - I recorded this using the features in OpenAL soft - i.e. set these parameters in ~/.alsoftrc (or %AppData%\alsoft.ini)

drivers = wave
[wave]
file = /tmp/testfileoutput.wav

Recording is here: http://www.mediafire.com/download.php?yl48wgo1gdcxynl

Does this sound like the drone you're talking about? It's not as clear as it is in game, but it's fairly close - the Subach firing sound is playing the whole way through, it's just hard to hear.

FYI - the flak sounds can be found in sparky_fs2.vp, data/sounds/:
8b22k/FlakLaunch.wav
16b11k/boom_4.wav

Lastly - and on a slightly different topic, I don't believe that the code to detect the number of available channels is working properly. I tried setting my "sources" in .alsoftrc to 16, but FSO started happily without any warnings. The sound in the test mission was woeful of course.

Looking at the code, it seems to just open a single channel and then close it straight away, it does this 48 times for each sound device. I've created a patch (vs 3.6.14, NOT trunk) which I think will fix this detection. Obviously, this will now disable sound completely if FSO can't find any devices that support at least 48 channels. What are your thoughts on this?

~0013825

iss_mneur (developer)

Last edited: 2012-07-04 22:31

View 2 revisions

Thank you niffiwan for your experimentation. It did help.

New patch with a new build that fixes the problem by restoring the behaviour of the sound code to that of 3.6.10. So yes, this does mean we lose some of the richness of the sound environment that taylor was originally trying to allow for when he rewrote this code.

Fundamentally there are two ways to fix this bug:
1) The fastest and least disruptive (which is what is being tested here) is to just restore the behavior of the sound code with respect to how it manages and limits concurrent sounds by enforcing the limits as requested by the engine, this is basically an extenstion of the fix for the ear breaking warpins.
2) Basically a rewrite of the sound code from top to bottom because the engine itself is its own enemy. There are many things that can be done in a from scratch rewrite that would make this work much better, sound, and behave much better with respect to these bugs, but this is a huge undertaking and something I don't think SCP has a resouces for at this time.

The patch for the new build is attached. The new build can be found here: https://www.box.com/shared/eef20e67b7bbda7c9ae9



=====

Now to answer some of you questions niffiwan.

Bumpping max channels did solve the clipping and truncation issue (based on what I was seeing during debugging the test mission used a maximum of about 65 conncurrent sounds. But it didn't fix the problem with the "drone" and unfornatly, its not really a viable solution unless we are going to force OpenALSoft on everyone.

No, Windows does not have a %AppData%\alsoft.ini but I did find a sample copy from: http://repo.or.cz/w/openal-soft.git/blob_plain/HEAD:/alsoftrc.sample and placed it. OpenALSoft did see it and use it though apparently the "Generic Software on *" devices do not honor it; I was able to record a wave with the alsoft.ini, but for some reason the drone was not audible.

That is close to what I was hearing as the drone, but it was lower pitched and not as clear. I think the drone is the first quarter to first half second of the flakLaunch.wav and Capital5.wav.

You are correct, the sources detection code is wrong and honestly while you solution is probably the correct one, I don't know how many hardware sound cards we would find that can actually do 48 voices so I think just disabling the sound if we don't have 48 is not really a valid solution espcially when FSO is actually able to dynamically use a smaller or larger number of max channels. Lets move this discussion to Mantis 2680.

@jg18: Please open an new mantis # with an log of the hang attached. It would also be interesting to see a stack trace from that crash if you can.

EDIT: Clarified what the patch does.

~0013827

iss_mneur (developer)

Just attached a trunk version of the patch after several requests about it.

~0013828

jg18 (developer)

Last edited: 2012-07-05 00:09

View 2 revisions

Trunk version of the patch works on Snow Leopard (OS X 10.6) with trunk and my OpenAL Soft build. I can always hear my gun fire, and there's sound from the capships, although I didn't listen to it closely. Well done, iss_mneur!

Although FSO still crashes on mission exit, so I'll have to look into that.

~0013830

niffiwan (developer)

I've done some testing with both versions of the patch with OpenAL soft 1.13 & 1.14. Primary sounds always play in the test mission, a fair bit of the flak is missing (as expected) but each instance doesn't seem to be truncated too much, unlike with some other tests at least one flak sound plays to completion fairly often which I think is better than all being truncated. When close to an Aeolus the flak launch sound mostly drowns out the flak detonation, but no big deal. Beam firing sounds seem to be all playing correctly as well.

Overall - looking good :)

~0013836

iss_mneur (developer)

Okay, good to hear, now to post in the RC6 thread.

~0013870

ZeroDivision (reporter)

Last edited: 2012-07-18 14:15

View 2 revisions

Both the regular RC6 and the one with the patch sound pretty much the same on my computer when flying through the ring in the test mission. The patched version seems to be a bit louder, especially the beams.

Windows 7 x64
Sound Blaster Live 5.1 or something
Generic Software in wxLauncher

ps. I'm new to this Mantis thing so bear with me :)

~0013888

iss_mneur (developer)

As reported by A8VR the take3 patch causes the voice audio to be cut off when the after burners are struck, but only the the afterburners (so far as I have seen).

~0013889

iss_mneur (developer)

Issue has been fixed. Patch attached. It applies on top of the current RC7 trunk (though the changes are so minor that it may work on trunk as well after putting the take3 patch on).

~0013891

iss_mneur (developer)

A build with the patch against RC7: https://www.box.com/shared/0586fed47e1963ece31d

~0013912

iss_mneur (developer)

Fix committed to trunk in revision 9113
+Notes

-Issue History
Date Modified Username Field Change
2010-07-19 14:29 chief1983 New Issue
2010-07-19 15:36 Renegade Paladin Note Added: 0012246
2010-07-19 15:37 Renegade Paladin Note Edited: 0012246
2010-07-19 15:50 chief1983 Note Added: 0012247
2010-08-05 16:09 chief1983 Target Version 3.6.13 => 3.7.2
2011-03-31 12:55 chief1983 Target Version 3.7.2 => 3.6.14
2012-01-27 14:58 chief1983 Assigned To => iss_mneur
2012-01-27 14:58 chief1983 Status new => assigned
2012-05-19 23:52 iss_mneur Note Added: 0013570
2012-05-19 23:52 iss_mneur Reproducibility always => random
2012-05-19 23:52 iss_mneur Status assigned => feedback
2012-05-20 17:38 chief1983 Note Added: 0013584
2012-05-20 17:38 chief1983 Status feedback => assigned
2012-05-20 17:39 chief1983 Status assigned => feedback
2012-05-20 18:42 iss_mneur Note Added: 0013586
2012-05-20 20:49 chief1983 Note Added: 0013587
2012-05-20 20:49 chief1983 Status feedback => assigned
2012-05-20 20:49 chief1983 Status assigned => feedback
2012-05-27 10:02 jg18 Note Added: 0013613
2012-05-27 10:02 jg18 Note Edited: 0013613 View Revisions
2012-05-27 10:03 jg18 Note Edited: 0013613 View Revisions
2012-05-27 10:25 jg18 Note Added: 0013614
2012-05-27 10:25 jg18 Note Edited: 0013614 View Revisions
2012-05-27 12:03 jg18 Note Added: 0013615
2012-05-27 12:04 jg18 File Added: fs2_open.osx.3614rc6.log
2012-05-27 12:05 jg18 File Added: fs2_open.osx.openalsoft.log
2012-06-11 02:47 iss_mneur Note Added: 0013659
2012-06-21 16:37 MjnMixael Note Added: 0013696
2012-06-28 00:14 iss_mneur File Added: Mantis_2266.fs2
2012-06-28 00:17 iss_mneur File Deleted: Mantis_2266.fs2
2012-06-28 00:17 iss_mneur File Added: Mantis_2266.fs2
2012-06-28 01:22 iss_mneur Note Added: 0013732
2012-06-28 06:02 niffiwan Note Added: 0013733
2012-06-30 05:59 niffiwan Note Edited: 0013733 View Revisions
2012-07-01 05:26 niffiwan Note Added: 0013755
2012-07-02 08:46 niffiwan Note Added: 0013792
2012-07-04 03:42 jg18 Note Added: 0013817
2012-07-04 03:43 jg18 Note Edited: 0013817 View Revisions
2012-07-04 07:51 niffiwan Note Added: 0013818
2012-07-04 07:52 niffiwan File Added: mantis2266-channel-detection.patch
2012-07-04 22:08 iss_mneur Note Added: 0013825
2012-07-04 22:09 iss_mneur File Added: mantis_2266_fix.take3.patch
2012-07-04 22:09 iss_mneur Relationship added related to 0002680
2012-07-04 22:31 iss_mneur Note Edited: 0013825 View Revisions
2012-07-04 23:34 iss_mneur File Added: mantis_2266_fix.take3.trunk.patch
2012-07-04 23:35 iss_mneur Note Added: 0013827
2012-07-05 00:07 jg18 Note Added: 0013828
2012-07-05 00:09 jg18 Note Edited: 0013828 View Revisions
2012-07-05 07:56 niffiwan Note Added: 0013830
2012-07-05 21:48 iss_mneur Note Added: 0013836
2012-07-18 14:12 ZeroDivision Note Added: 0013870
2012-07-18 14:15 ZeroDivision Note Edited: 0013870 View Revisions
2012-07-30 23:42 iss_mneur Note Added: 0013888
2012-07-31 01:23 iss_mneur Note Added: 0013889
2012-07-31 01:23 iss_mneur File Added: mantis_2266_take3_followup.patch
2012-07-31 22:41 iss_mneur Note Added: 0013891
2012-08-16 01:19 iss_mneur Note Added: 0013912
2012-08-16 01:19 iss_mneur Status feedback => resolved
+Issue History