beta 4 delayed

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.

7 Replies to “beta 4 delayed”

  1. X-Plane 10 will likely work too, just as X-Plane 11.36 and earlier probably did.

    From a comment in (I added the text between []):

    Yes – this is that issue, and should resolve problems for plugins like XSB (although it is not the only one I heard about) that have audio services _inside_ the plugin and not in a separate helper app.

    The issue is that in 11.36 [or earlier, including XP10] we didn’t have any security entitlements set at all, so the OS assumed that we _might_ ask for anything and would ask the user for mic access when a plugin opened an audio source.

    In 11.40 we list a bunch of entitlements explicitly (E.g. code-gen execution so Lua plugins can work) and we left the mic off. Having “actively omitted it” from a positive list of security entitlements, the OS interprets that as “those LR guys say they DO NOT need the mic, so if x-plane asks for the mic, it’s infected by spyware, just deny it”. No user prompt.

    In 11.41 we added the mic entitlement to our list, hopefully fixing the issue. Only X-Plane could fix this – plugin DLLs don’t get security entitlements, as it’s on the process level.

    Thus, as far as I can tell, the only release that was actually ever broken re: macOS microphone support was 11.40, it just happened that its release coincided with the release of AFV and the XSB 2.0 Beta cycle…

    1. Working is not the same as supported – as I reiterate a number of times: if it works, it works – but if it doesn’t, I can’t (really) do anything to fix it.

  2. Roger re: support vs. working. I somehow misunderstood it as though you would disable it intentionally under macOS+XP10, which doesn’t seem necessary 🙂

    Any chance you’ll be able to spin new test build before Xmas?

  3. Beta 3 hotfix 2 not working on Kubuntu 18.04. Plugin will not open any windows (preferences, about, etc) and the connect (and disconnect) options are always grayed out

    1. Ah that explains it. Is there a working beta out then, or do I have to wait to fly on VATSIM until a new one is released?

Comments are closed.