Update: The hotfix is now available for download.
I’ve just tracked down the cause for a crash on some macOS systems which is related to the opus audio codec.
This bug affects all macOS systems that use CPUs that do not support AVX. AVX was introduced in 2011, so all mac systems from before 2011 will not currently work because of this issue. Mac systems from after 2011 that use an older CPU (such as the 2012 MacPro hex-core) also will not work.
The crash will be characterised by X-Plane crashing when a connection is made, or the audio setup dialogue being displayed. The macOS crashlog will indicate “
Exception Type: EXC_BAD_INSTRUCTION (SIGILL)” with the crashed thread crashing in
silk_VAD_Init + 4
Unfortunately, the opus team accidentally force-enabled AVX optimisations in their build tooling for opus, and so if the library is built on any AVX-capable mac, the result uses AVX, irrespective as to any options we set to inhibit that support.
I’ve patched the XSquawkBox libopus to disable this and as long as this doesn’t break the Linux build (the same options get used there), this update will be published as hotfix 2.
If you are using an old Mac – please hold off further bug reports until beta 4 hotfix 2 is published.
XSquawkBox 2.0 beta 4 hotfix 2 is up on the Downloads page.
(hotfix 1 has been released to address a build issue with portaudio that resulted in the macos 10.15 dependency creeping back in – it contains no other changes and should work on older macOS releases now).
(hotfix 2 has been released to address a build issue with opus that resulted in AVX optimisations always being present on macOS and possibly Linux as well)
This release incorporates a number of bugfixes as well as a reversion to the older portaudio sound driver. More importantly, macOS 10.14 and newer are supported again when used with X-Plane 11.41 (or newer).
Continue reading “XSquawkBox 2.0beta4 Released”
XSB 2.0 beta 4 is coming, but it’s going to be a few days late. I have a few obligations I cannot move that are preventing me from making the release before b3 expires.
Key points of beta 4:
- Reversion from the libsoundio driver back to portaudio. (portaudio was generally working more predictably than libsoundio has been).
- Exposure of various internal audio stats via dataref to aid debugging.
Finally – macOS 10.14/10.15 support is back, thanks to Laminar including the necessary permissions in X-Plane 11.41 – however, the proviso is: Only for X-Plane 11, and only for 11.41 and newer.
I can’t and won’t support X-Plane 10 on macOS 10.14 and newer – if it works for you great, but if it doesn’t, please don’t report the bug – I can’t fix it if it’s not working and it’s not reasonable to ask Laminar to implement the hardened runtime and the necessary permissions for X-Plane 10.
There’s a few specific goals for the beta4 release:
- Audio driver – the headache with macOS turned out to be 10.15’s security model, so we’re going back to the older, more stable, audio driver. We need to make sure that with the improvements I was forced to make by the soundio driver, we’re still just as stable as we were previously.
Audio Compatibility Improvements – in the soundio port, I had to add support for stereo playback devices. This support will get added to the portaudio driver before b4 is released. (ed: I forgot the management of the playback buffer was different enough to make this non-trivial to port – will look to adding it in a future update to AFV-Native, but not holding up beta 4 any longer on it – CC)
- This doesn’t fix the sampling rate limitations – most of those can be dealt with by adjusting operating system settings or are a direct consequence of your hardware.
- On windows, look at the Audio Device properties and change the default sampling rate.
- On macOS, run “Audio MIDI Setup” and change the device sampling rate.
- In all cases, the OS-level sampling rate must be set to 48,000Hz to work if portaudio is not able to do that automatically.
- 1 hour audio failure bug – I need more data for this and I’m not declaring XSB 2.0 final until it’s either proven to be external, or it’s fixed. It sounds like this bug is not dependent on the sound driver from the one report I’ve had of it, so it’s probably been present for a while.
- The manual – I finally started rewriting the manual using sphinx and read-the-docs – the repo is live and user contributions to the manual are strongly encouraged (submit a pull-req with your contribution, and if you want to avoid conflicts, submit a issue first and coordinate that section of the manual with the other contributors and myself!). I don’t have a lot of time for this myself right now, so I’m mostly working on it when I have a few free moments.