Reporting Issues, USB Audio, the path to 1.3.3 final, and the future

A quick post on a few very important matters.

TL;DR version:

  • Fill out bug reports properly or they simply won’t get read.
  • Please don’t use magical fixes for USB audio problems, but report them properly.
  • 1.3.3 final is coming but might be a while.
  • Old style CSLs will be going away in the future.

Please read on for the details.

Reporting Issues

As I’m finally able to spend significant time on XSquawkBox, I need everybody to do their part when it comes to reporting issues.  To this end, there is now a bug reporting form.  

Please read the instructions in full and check the known issues and reporting requirements list BEFORE you try to submit anything.

If you do not obey the instructions or meet the reporting requirements, I will be forced to discard the report.

By the converse, I will endeavor to reply to all properly completed reports within 3 days – although I can’t guaranty a fix for issues in that time, I can at least let you know that you’ve done the right thing and I can proceed with the investigation, or request any additional information should it become apparent that I need it.

The requirement to paste the contents of your log.txt is compulsory for all issues.  I’ll see about making this easier (got to find a better plugin for WordPress), but if you just type garbage in, I will just bin your report.

Reporting issues is not a substitute for user support – I do request you try to seek help with other users through the x-plane.org and VATSIM forums.

Reporting issues is not for network related matters – I cannot help with any CID or password related errors at all.

Reporting issues is not for feature requests.  My official policy on feature requests is that I simply do not field them.  There’s already too much work to be done.

USB Audio

I keep on seeing posts from a few specific users about USB audio problems. As I perform all of my primary testing with USB audio hardware, I can assure everybody there are no problems inherent to USB audio itself – it’s most likely specific devices or some strange interaction I can’t personally reproduce.

I am willing to hunt this one down, but as I can’t reproduce it, it requires anybody experiencing the problem to actually perform reasonable diagnostics and conduct good reporting.  Telling me that it “still doesn’t work” literally tells me nothing.  The log.txt files are more important for this issue than ever.

There also seems to be some myths floating about in regards to USB audio, so let me dispel these now with a few truths:

  • You should never need to edit the preferences file by hand.  If you do need to edit the file to make audio work, please make sure you file an issue with a full description of everything you tried before editing the preferences file.  If you don’t help by filing issues properly, it can’t get fixed.
  • The squelch/mic test cannot be skipped.   You MUST perform the mic test otherwise XSquawkBox cannot use the microphone.  The test is used to do the basic internal gain adjustment, and if XSB reports the mic as hot or cold, please adjust your recording gain appropriately in your operating system mixer and try again.  If the gain is out of range, even if the microphone is working, the voice codec will probably be unhappy and your voice will be distorted.
  • Setting the audio settings, closing and then reopening the audio settings is not an acceptable test.  I would have thought that one goes without saying when you’re already having problems, but as the preferences and the internal state are quite separate, you really do need to test audio settings through actual use to confirm what’s actually happening.
  • You must not use any flight plan pre-filing tools when testing audio.  Unfortunately, past XSB maintainers thought it was a good idea to let third-party software provide flight plan data to XSB to submit by editing the preferences file.  This is actually a terrible idea as it’s race prone – you can very easily lose changes from one side because of the other trying to act simultaneously.

Towards 1.3.3 final

1.3.3b1 has two bugs I’m chasing before I make a final release.

One is the USB audio issue – if I can get the data I need to find out why it’s breaking, I will fix it before I roll the final release.

The other one is a rendering glitch where OBJ8 CSLs are rendered as lights only.  (Independent of the recently discovered xEnviro rendering glitch)

Unfortunately, I need to write a testing plugin for libxplanemp so Ben can help me debug this one.  Somehow we’ve made it all this time without one – simply testing in client.  This is probably going to eat significant time to sort out.

On the up-side, I’m trying to ensure that the test plugin can be used by CSL authors to test their CSL models without connecting to a network.  No point doing this twice, and having a way to debug libxplanemp off network will be beneficial to both XSB and to the swift project (and maybe even X-ivap if they ever update their client).

1.3.3 final will not be released until we’ve identified the source of this problem with OBJ8 CSLs.

The Future

Whilst I don’t like publishing timelines or committing to features before I’ve got them at least partially implemented, there are changes coming to XSquawkBox in the (hopefully) near future.

1.3.3 will most likely be the last release of the XSquawkBox 1.3 family, with the next release being a feature release.

 

What I can guaranty in the next feature release:

  • 32-bit support will be dropped.
  • X-Plane 10 will still be supported.
  • Keyboard mapping will be redone to use the X-Plane command system – this will also mean that any actions will be able to be bound to a joystick button in the future.
  • It will include ACCONFIG support.
  • LegacyCSL rendering will be dropped when X-Plane 11 implements non-OpenGL based rendering.

The last point is particularly important.

The past few weeks have seen the first real OBJ8 CSLs for XSquawkBox enter distribution and I’m putting significant effort into ensuring that they work properly.

Ben has already stated in the dev-blog that we should expect the method that we use to render LegacyCSLs to become non-viable at some point in the 11 release cycle, and to be gone by 12.

The OBJ8 CSL rendering code already uses X-Plane to do all of the heavy lifting, and should continue to work when X-Plane moves beyond OpenGL.

Rather than drag the demise of the old CSL format out as long as possible, and risk forcing users to stick with OpenGL rendering, when Laminar ships a X-Plane build that offers non-OpenGL based rendering, Legacy CSL support will be removed from future versions of XSquawkBox.