Users are reporting that since SU5, All our MSFS2020 aircraft [FlyInside] have sounds that are either missing completely or pitched so low as to be inaudible. This is easily seen on our Bell 206 the overhead switches either do not work, or work in one direction and not the other or are pitched low. Also, blade slap trigger does not play any sound.
These are NON-wwise sounds. We are not currently using wwise.
An while we are at it, the exhaust plume is straight up to >20k ft.
This is our current versions.
No changes on our end.
Yes, Sylvain, that is the issue. But it is not nearly as important is the missing and/or incorrect sounds.
This is an example of the copious number of emails/discord messages we are receiving regarding sound issues. Nothing was broken before. What has changed in the implementation of legacy 2020 sounds?
āā¦i bought Bell 206 yesterday on msfs2024 Marketplace Xbox. Great Handling and superb textures. But the outside Sound is very crap. Loss of Rotor Slap, loss of engine sound, It sounded like I still had the sounds of wind and Exhaust, so that is strange.
What can be the Problem. Does anyone has the same Problem?ā¦.
Any updates on the sound bug? This is affecting not only our products and our user base, but new products we have are being held for release. It is also, affecting other developerās products.
I have this issue with short ātriggeredā WAV sounds in MSFS 2024, the most notable example is the percussive āclickā sounds applied to switches.
What I discovered was my issue is MSFS 2024 skipping the first 0.1 seconds of the WAV file, so the click was inaudible and āclunkā on glider spoilers being unlocked was missed entirely but the ākerrlunkā of them being closed was still (partially) audible.
This issue was common to me and others flying my planes, but the problem doesnāt necessarily occur when you first spawn into the sim.
My āfixā has been to add 0.12 seconds of silence onto the front of the WAV files, so e.g. the āclickā is heard ok, and the fix only involves benign changes that shouldnāt break on future Sim Updates.
Hey B21 thanks so much for this insight, I work with Rick on sounds and with your 0.12 fix we were able to hear our switch clicking sounds again. The only remaining issue is that there is a low pitched āclunk shhhā sound that remains playing underneath our switch sounds. I have combed through our sound.xml code and there are no pitch adjustments being made to where our switch sounds are triggered. Do you have any insight into what this might be? We cannot seem to track down what is triggering this extra low pitched clunk. Almost as if its the click sound being played twice but one is at a regular pitch and one is pitched down several octaves. Thanks again.
I think thatās unlikely to be a straight MSFS bug (but I could be 100% wrong). Are you also including a stock `<MainPackage Name=XXXā¦` in your sound.xml and itās possible that could be injecting an unexpected sound? Simple check would be to delete that entry and re-listen to the click.
Hey B21 thanks for the reply, I will double check this but our main issue is that all of our sounds for every helicopter worked perfectly about 4 weeks ago with no changes to any sound.xml code. And what Rick is talking about in his initial post is that there seems to have been some kind of msfs update or change that has also broken the sounds of a helicopter that has worked perfectly for years up until a few weeks ago. And has not been iterated upwind in anyway. So that is what has lead us to believe that there has been a change under the MSFS sdk or how it handles audio that has broken our in progress helicopter and the older untouched ones. Thanks.
And just to be extra clear this added low pitched sound that weāre hearing underneath the switch sounds was also NOT present until a few weeks ago as well. Seemingly appeared out of nowhere but we assume after the recent SDK update. Although I have installed older SDKās to check if it fixed the bug but the issue persisted which is strange. These audio bugs all occurred without any iteration to our sound.xml files in either the in progress helicopter and the completely finished 2020 one. We have to assume we canāt be the only ones affected by this.
ah unlucky - I just went back in and checked and I donāt hear the "low pitched āclunk shhhā sound under our switch sounds, and given itās a glider Iām absolutely sure Iād have heard it if it was there at all.
Yea itās incredibly strange and especially so for the 2020 bell 206 helicopter which no one has altered or worked on in several years. So if anyone has any idea as to what it might be, weāve been slamming our heads against the wall for a few weeks now. Any help would be appreciated.
I am placing a more in depth report here incase anyone at Asobo can take a look at this or comes across more reports. All findings seem to lead to a change within SU5:
ISSUE DESCRIPTION
Since SU5, all SwitchUp and SwitchDown sounds in SimVarSounds are playing with an additional low-pitched ghost instance layered underneath the correct sound. This affects all switch entries regardless of which LocalVar is being monitored.
REPRODUCTION STEPS
Load any aircraft using XML-only sound implementation (no Wwise) with SwitchUp/SwitchDown entries in SimVarSounds
Trigger any switch sound
The correct sound plays but with a second, lower-pitched version of the same sample audible underneath it
ADDITIONAL FINDINGS FROM INVESTIGATION
The bug is present on aircraft that have not been modified in years, ruling out any developer-side change as the cause
The ghost instance responds to PitchCurve changes ā when pitch is explicitly set to 1.0 via PitchCurve, the main sound corrects to normal pitch but the ghost layer remains, indicating the sim is spawning a second audio instance that partially but not fully responds to XML pitch overrides
Removing the Sound entry entirely removes the ghost as well, confirming the ghost is being spawned by the simās processing of the Sound node itself rather than being an external injection
The issue affects every SwitchUp/SwitchDown entry in the file regardless of which LocalVar triggers it, which WwiseEvent slot is used, or what VolumeCurve settings are present
This implementation worked correctly prior to SU5 with no changes on the developerās end
I totally get the āunchanged packages have stopped working properlyā status so my comments added here arenāt going to help directly, but in case itās of any useā¦
Hereās what I have for the switch click sound. In both 2020 and 2024 the RPN XML just toggles the L:SOUND_CLICK simvar 0|1 when the switch node is clicked and plays click.wav and meanwhile the model RPN updates an O: animation variable local to that component to move the switch. The glider panel is compact enough all the switches can share the same sound element / model node āsourceā, otherwise itād need to be L:SOUND_CLICK_VARIO etc. This doesnāt give an independent volume control for the clicks though.
Our variometer tone varying lift ābeepā does use the <VolumeCurve><PitchCurve> variant of the Sound entry as listed below. Given the B21_SOUND_VARIO_MS value of 2.0, i.e. pitch point of 1.0, the sound does play exactly the same in the sim as it does in Audacity and I do NOT hear a low-frequency shadow sound. Minor tip: MSFS limits the PitchCurve to between 0.5 and 2.0 so you need to use that range for the max 2-octave pitch change, i.e. 1.0 to 4.0 could theoretically work the same but caps at 2.0. In the example below the pitch only needs to rise and the WAV is actually double the desired start frequency.
The WwiseEvent=āSTALL_WARNINGā seems needed above (not sure why any Wwise event is needed for a WAV). The WwiseEvent=āvolume_pitch_testā example given in the SDK simply causes the entry not to work at all. I think this has always been true but itās undocumented so not sure. The LocalVar entry in the Sound element might not be needed but given the valid Wwise event IS needed and this entry has always worked I havenāt risked changing it.
Outside of a bug in the SU5 sound system, the only thing I can think of that might cause the shadow sound would be maybe the interior/exterior model XML fighting over the value of the pitch-controlling L simvar (or XML vs html/js). Unlikely in an unchanged model, I know.
Hey B21 I really appreciate you sharing this code. It definitely helps to see how its working for you. Yea I have reason to believe it could be within the interior/exterior properties and how they were affected by the new Sim Update. I am also going to try rewriting some of our switch code just to see if I can force it to be regular, (which Iāve had no luck doing so far). But I wanted to post the code structure we use for a typical switch sound here. Its very close to how yours is handled but a few differences-- One being Iām setting volume curves in the function. Thanks again for all the insight. Will update if anything changes. The battle rages on.
AMAZING! Thank you for getting back to us here EPellissier! Weāll keep an eye out for your updates. And do let me know if you need any more info from our end. We really appreciate it.
A fix candidate for the sound issue reported by @RotorRick00 will be included in the next update of the 5.1 beta builds. @bodymeatco, we did not reproduce the āghostā sound you reported later on but we will be very interested to know if it still occurs with this next build.
The FX issue still needs to be carefully investigated but it might be due to some conflicts between FXs inclided in two different add-ons. Iāll confirm as soon as I know.
Hey Eric thatās so great to hear! We really appreciate the communication.
Yea I have no idea what could be really causing that in our situation but Iām certain it wasnāt in either aircraft before the update. Either way we will definitely let you know if it has fixed our issue once the update is live. Thanks again.
The fix I was mentioning earlier is included in SU 5.1 1.7.32.0 which was released last night on all platforms (warning: this is a beta version). Would you mind checking if the bug you reported is now fixed?
