NASSP
NASSP copied to clipboard
orbiternassp
Implement XRSound
As we know, OrbiterSound 4.0 is not officially compatible with Orbiter 2016. While it does run without too many issues, there are some good reasons to make the switch, such as (not limited to) these issues:
- 3D audio causing low frame-rate at session start until a sound is played.
- Weird rumbling noise heard around the time of pitch-over during P64 .
- Radio/mp3 Panel MFD causes a CTD
XRSound: https://www.alteaaerospace.com/ is the best candidate right now for a new sound solution for NASSP. Currently OrbiterSound is deeply intertwined in NASSP code so it will require a fair amount of work to successfully transition over to XRSound but the in the long run this should be good sound platform for NASSP 8.0+
Would it be a good idea to hook up XRSound in a way so that it can be easily replaced again if at all possible? Just in case something like this were ever to happen again.
XRSound does have a wrapper module for OrbiterSound calls, although its success is kinda marginal, IMO. But I haven’t seen any buzz about whether or not OrbiterSound 4.x for 2016 is dead in the water.
From: Thymo [email protected] Sent: Wednesday, May 29, 2019 15:18 To: dseagrav/NASSP [email protected] Cc: Subscribed [email protected] Subject: Re: [dseagrav/NASSP] Implement XRSound (#474)
Would it be a good idea to hook up XRSound in a way so that it can be easily replaced again if at all possible? Just in case something like this were ever to happen again.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dseagrav/NASSP/issues/474?email_source=notifications&email_token=ADHTXBPDDYEIHCBDTNPQ3PLPX3JFNA5CNFSM4HQQR6B2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWQL3RY#issuecomment-497073607 , or mute the thread https://github.com/notifications/unsubscribe-auth/ADHTXBPLUADO7HZVKBPFDHDPX3JFNANCNFSM4HQQR6BQ . https://github.com/notifications/beacon/ADHTXBLSH6BZTDFFVOZTLM3PX3JFNA5CNFSM4HQQR6B2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWQL3RY.gif
If you decide to do this I need to know about it before you commit so I can repack the autobuild resource bundle with xrsound instead of orbitersound.
If you decide to do this I need to know about it before you commit so I can repack the autobuild resource bundle with xrsound instead of orbitersound.
Sounds good. It will probably take a while before we get it implemented but we'll coordinate it with you when the time comes.
With OrbiterSound 5.0 complete, which supports Orbiter 2016, is there still a need for a port to XRSound?
Bumping because if we plan to target OpenOrbiter for future releases, OrbiterSound 5.0 uses an incompatible runtime library (static vs. dynamic runtime) that causes (as far as I can tell) unfixable linking errors. I don't really have the skills personally to execute such a conversion on my own, but after three days of work I am still unable to link both OrbiterSDK and OrbiterSound, only one or the other. Not only that, but OpenOrbiter natively implements XRSound, so a conversion to that sound engine would be a sensible thing to do IMO.
