Jump to content

Timothy Walker 1294725

  • Content Count

  • Joined

  • Last visited


Community Reputation

0 Neutral
  1. Appears caused by XSB; I was doing nothing specific at that point (aircraft parked, was in the kitchen getting a coke). Crash log: https://pastebin.com/mb4gwBRx X-Plane log: https://pastebin.com/8xiFHXA1 There doesn't seem to be much to go on, any idea?
  2. Just to confirm, the recently released beta4 hotfix 1 supports all of my stereo inputs and outputs, so it probably handles up/downmixing automatically. Thoughts on my last question?
  3. TBH a quick look seems to indicate the PortAudio API does seem to support my stereo-only mic as configured in the AFV-Native code, I guess it has built-in downmix somewhere? I got the test client built, but probably won't be able to actually test it on my sim machine until Tuesday. I might also see if there's something I can do about the SoundIO path, though since XSB is apparently going back to PortAudio, I won't spend too much time on it. Do you have a preferred/recommended way to measure the AFV-Native capture loop performance so I can check the effect of a basic downmix?
  4. Thanks, will try and take a look some time this week
  5. XSB2 already uses the individual radio volume datarefs (this came in with all the other audio-panel/mixer support changes) - currently, however, it's presently using linear scale - this will be fixed to logarithmic scale at some point. We do not use the global dataref because that has other implications which we do not want to interfere with. Aha, I must have only tested the global dataref then. As long as one of the datarefs work, I can work with it, thanks
  6. Not happening anytime soon unless somebody else contributes the downmixer to AFV-Native in a way that doesn't kill the capture loop performance. It's too much of an edge-case given that we strongly recommend headsets and the majority of headset mics are monaural only. Are any of the relevant parts of XSquawkBox open sourced? If so I could take a look at it.
  7. Since we're currently in a Beta phase triggered by the need for AFV support, I figure now is not the worst time to ask for some features to be squeezed into this development cycle. I would like to kindly request the following: (1) support for stereo microphones >>> see related: viewtopic.php?f=109&t=80710 (2) remember positions of the "text" and "who's online" windows/overlays (3) remember the state of the "use radio effects" checkbox, doesn't seem to work right now (4) ideally, re-introduce volume control for the selected audio output >>> I have sim
  8. OK, so the plugin/AFV seems to expect 1-channel @ 48,000 Hz, and maybe doesn't care about the sample format. I went back to XSB 1.3 for testing, and the mic setup dialog was able to use my 2-channel mic using the "setup mic" dialog to record and play my voice back without issues or complaints. I understand the Opus codec and/or encoder only accepts 48 kHz input and software resampling is a PITA to implement, but requesting 1-channel input when 2-channel worked fine before seems like a pretty annoying regression. A proper downmix is not that hard, but if it's too tedious, surely discard
  9. XSB-AFV-Native: Sat Dec 14 20:06:46 2019: AudioDevice: device Built-in Microphone - can't handle sampling rate. XSB-AFV-Native: Sat Dec 14 20:06:46 2019: AudioDevice: device SB Omni Surround 5.1 - doesn't support monaural audio So I gather XSB 2 requires mono input, but what sample rate(s) and sample format(s) are supported? The log doesn't mention that. In case of incompatible devices, it might be nice to log what XSB wants, as well as the detected capabilities of the device?
  10. Thanks. I'll give it a try, would be nice to be voice-ready in time for WorldFlight
  11. There are instructions on how to use the standalone app with Linux? Can you point me to them please?
  12. Does swift support the new audio codec out of the box already? Otherwise all macOS users remain text-only at the moment, since the standalone client is Windows-only.
  • Create New...