"RtApiPulse::probeDeviceOpen: unsupported sample rate" error on launch

[JPLeBreton]

Was able to compile the linux_port_implementation branch with no issues on my Manjaro system. When I run it, though, I get this error:

[Main] The Force Engine 
v0.70.000
[Paths] Program Path: "/home/jpl/game/forceengine_linux/TheForceEngine/"
[Paths] Program Data: "/home/jpl/.local/share/TheForceEngine/"
[Paths] User Documents: "/home/jpl/TheForceEngine/"
[Paths] Source Data: "/home/jpl/game/dark/"
[Startup] TFE_System::init
[Display] Vertical Sync enabled.
[RenderBackend] OpenGL Device Tier: 3
[Startup] TFE_AudioSystem::init
terminate called after throwing an instance of 'RtAudioError'
  what():  RtApiPulse::probeDeviceOpen: unsupported sample rate.
Aborted (core dumped)

[gilmorem560]

Might need to consult with your provider on your RtAudio package, it seems the error is happening down in there. There is also a bundled version the Windows build currently uses, you can use the built-in by taking out the RtAudio related bits from AUDIODEF and AUDIOLIB in the Makefile and then add the RtAudio and RtMidi .o files to the AUDIO section of the object listings. This was the last library that I re-pointed to a shared object on my machine, so that got the least amount of testing, but I also don't seem to get this error with the version I've got installed. I'm not at my personal computer currently, so can't tell you what specific version I'm building against.

Other suggestion is just toss a breakpoint on AudioSystem::init and see what might be going on down in there.

[JPLeBreton]

Hmm, okay so I ventured in with a debugger, not really knowing much about TFE's internals and flat zero about RtAudio.
Following the execution around, I got to audioSystem::init and the call to TFE_AudioDevice::startOutput. All the settings it was passing in seemed reasonable to me, but my guess was that one of those was causing the "unsupported sample rate" error. I naively tried changing the sampleRate parameter from 11025u to 44100u, recompiled, and got to the menu screen! (Of course, this meant the 11KHz game sounds were playing at 44KHz, so it wasn't exactly playable.)
So my guess is this is something about my setup + RtAudio. The first possible culprit might be Pipewire, ie the newish audio system that, looking at the RtAudio repo's issues page, doesn't directly support. So I'm going to try switching back to PulseAudio from Pipewire and seeing if TFE can run unmodified. I'll report back if I find out that's the issue, as it's likely something Lucius will have to contend with when adding official Linux support.

[JPLeBreton]

Okay, switching from Pipewire back to Pulseaudio would be way more Linux Hassle than I'm willing to deal with at the moment, so I'll have to leave that hypothesis untested for now. Does your system use Pulseaudio or Pipewire? If it's the former, I'm betting that's why the code works fine on your system. I'll dig more on RtAudio's side - its development seems to proceed pretty steadily.

[gilmorem560]

I'm sure I have PulseaAdio installed, but in the Makefile I have it trying to build the ALSA backend. Off the top of my head, RtAudio has ALSA, OSS, and PulseAudio backends available. I'm surprised it's trying to do anything at all with PulseAudio, unless you've modified the Makefile. I opted towards ALSA for the time being since each and every Linux system should have that.

I wish I had more to tell ya, most code I've written myself has been OpenGL stuff, but I've never gotten around in any of my engine attempts to a serious jab at audio, I've only played briefly with the PCM interface in ALSA, and have read some documentation on OpenAL, but can't say I've ever truly written any audio code.

[gilmorem560]

Also worth noting, I don't have audio right now, I twiddled things enough to get it to build and run, but haven't started diving into the actual errors I get there yet. If you actually are getting sound, it's just garbled when you set a different sampling frequency, then perhaps you're actually further along in some respects than I am.

[gilmorem560]

Haven't gotten back around to this yet, one thing to note is the Windows build pulls in all of the dependencies as explicit DLL references whereas I've adjusted the Linux build to look for shared objects. I think the copy of RtAudio in the trunk is even included as source, I couldn't tell ya if there are any changes from upstream, but that may be a compelling place to investigate if you're interested, would be a matter of 1. vetting whether changes between the bundled version and your installed shared library could be involved and 2. vetting whether there are custom changes to RtAudio that no amount of version matching would resolve. If the latter winds up being the case, those are good candidates for shims that do the custom stuff instead so this can use vanilla dependencies.