It will not launch unless you have PulseAudio!

I found a fix. They have included their own SDL2 libs that are linked with PulseAudio.

If you remove or rename the file:
"~/GOG Games/J U L I A Among the Stars/game/lib64/libSDL2-2.0.so.0" (If you run 64bit)
or
"~/GOG Games/J U L I A Among the Stars/game/lib/libSDL2-2.0.so.0" (if you run 32bit)
Your systems SDL2 library will be used instead. Works for me. I can now play the game.

You mean one of the 5000 bog standard audio systems on Linux?

Thankfully, I've already got this one.

I was wrong to call PulseAudio a sound system. Its actually not.
There is actually only one that is active today ALSA. The old OSS system is not used much anymore. PulseAudio is a layer on top of ALSA and tries to solve some of the old problems ALSA use to have. They have been fixed so the sledgehammer approach of PulseAudio is no longer needed... Sadly much software is already written for it so it is used a lot even though its really deprecated since it does not contribute anything anymore.

PulseAudio is the userspace backend in Linux system, not ALSA - ALSA is audio kernel driver. Applications are expected to link against Pulse, not against kernel interface.

If you don't use PulseAudio, which is a special case, then use Pulse-to-alsa pass-through project like this one.

The "system libsdl" solution is not reliable, because libsdl is known to ABI-break (segfault) on update which causes loss of audio and input controls, hence why some proprietary applications ship local versions of libsdl (including JULIA). Still, but hot-wiring libsdl to alsa, you do not solve what Pulse solves, like reliable multistream mixing (for example, getting system notifications while game is playing background music).

This topic reads like "WARNING! JULIA REQUIRES LINUX KERNEL (GLIBC/LIBGL/XORG etc)!!" Pulse is not a "layer", its a sound server.
It does not "try to fix some problems", it implements big part of functionality that modern OS audio system is expected to provide, it is what Xorg/Wayland are to window management. What exactly has been "fixed"? If you write to framebuffer instead of proper window management, it is not "fixing" but "hot wiring". THIS is a "sledgehammer approach".

If you want depreciated, look no further than GStreamer. ALSA is actually built into the kernel. Or Phonon, which has been entirely replaced by QT multimedia.

The problem is that stability freaks like any Debian distro only bother to recompile all their packages into upgraded versions once every two years (no really) which may have worked in 1996 back before git even existed, much less github, but now those two years can be the difference between, "Here's a cool new technology" and "This technology died two years ago, why are you using it?"

This is compounded by the fact that many popular versions of Debian distributions, namely the Ubuntu family, use not only their own package repository, but also tend to be based on a long term branch of some previous Debian. So you go from two years to ???. For example, Xscreensaver is stuck on the October 2015 build in Linux Mint, and Debian won't get the fully updated edition until Stretch.

Now Xscreensaver is just a collection of screenhacks. That isn't too bad, you might think, but the problem goes deeper. For example, desktop environments are currently in transition from X to wayland, and may of them are several point upgrades behind in main Debian releases, meaning that not only is the widespread adoption of and development for Wayland going to be delayed, but there's a good chance that bug and feature requests would be bogged down by useless requests for features that have already been implemented, and ask for bugfixes that came 5 minor releases ago.

Such as is the case of complaining about a major, game-breaking bug in a little GNOME desktop game that was fixed two and a half years ago, when the only needed a bugfix-only point release upgrade (from the latest Mint version x.y.z to ancient version x.y.z+1) to get the fix. This upgrade would have fixed multiple major issues.

Now, Debian users, rather than demand that Debian maintain a policy of updated packages, make things harder for the end users by making them jump though hoops with stupid half-solutions like PPAs (Which are neither maintained, tested or even compatibility checked by any major authority), and Backports. Which then leads to the major bugbear: Legacy code.

(I mean I suppose you could also build from source, because compiling C+ code is exactly what I expect grandma to do.)

I'm sure you get the idea of what a lovely issue this becomes quickly. Having to not only be aware that some users are still running the 4.4 series of the Linux Kernel (as Linux Mint had been running by default when I had first installed it on my father's spare drive), but also that the users will be inheriting the mess from Ubuntu's LTS Xenial Branch as of the current version as of this writing.

TL;DR: And that's why things are so broken.

Thanks for the info! But what are you using yourself? There is no distribution that has all of:
1) has a huge collection of software,
2) which is mostly binary to save-up compilation,
3) manages configuration updates proper without manual interaction

AFAIK I only got things really "broken" on Gentoo during libpng upgrades. For Debian same thing was just a regular update. Also, I get latest softwares from PPA with nothing broken and ability to switch between versions as I see fit thanks to apt prefs.

Actually, they link against SDL2 which pulls in PulseAudio (in their configuration).
Sane people do not use unnecessary software in their machines and PulseAudio is totally unnecessary. This is the FIRST game (or software (except software written explicitly for PulseAudio of cause)) ever that I have seen that is shipped with PulseAudio dependencies and their software runs just fine without PulseAudio. (Actually better. I have read that PulseAudio gives audio stutter in this game that makes it unplayable for some people)

Oh, and ALSA multiplexes and mixes just fine. Don't drink the coolaid. The problems in ALSA that PulseAudio was written to fix is fixed. A normal person would have submitted patches to fix the problems in ALSA, not written a massive piece of buggy software to sit on top of it and try to maneuver around them.

Fedora. You know, that big branch of RHEL?

Sure, but the repo size and reinstall requirement beats it for me.. Yes, the matchstick engineering elitism. Oh, and no ALSA fixed nothing: people still with text config that [url=https://github.com/mopidy/mopidy/issues/889#issuecomment-63711779]barely works, with any application still hijacking the mixer, finding out best resample rate manually instead of pulse doing it for themselves, without ability for per-stream interactive volume control and tunneling. ... Just like in early Arch days, when vanilla configs just drop from the sky without any automatic 3- or 4-way merging. ... Or in devfsd era with manual module probing. ... Or unforgettable single Xorg.conf before HAL where user defines every device section and even one mistake breaks server. The "keep it simple - do ten thousand keystrokes" principle. nostalgia!

My magic "coolaid" makes system just running, taking enormous 20MB of RAM! Sure, invent your elitist bicycles any time you want, as race cars simply occupy too much space (pulling the very same dependencies) and are totally unnecessary! Beside, they make fingers lazy!

"PulseAudio gives audio stutter" its actually other way around - its glitchy ALSA drivers, which get exposed with Pulse's new timer-based scheduler.

"matchstick engineering elitism" I do not even know what that means.
I do feel your pain though, you seem to have a lot of problems with your machines. I have seen none of the problems you are talking about and I use and work with Linux every day.... I do not run Gnome though. Maybe that is where your problems are coming from? I suggest Openbox. Its marvelous!

Also: HAL!?!? People still use HAL?

""PulseAudio gives audio stutter" its actually other way around - its glitchy ALSA drivers, which get exposed with Pulse's new timer-based scheduler."
At least we can agree on PulseAudio not being needed since it even breaks the under laying software and thus makes the system perform worse that if it had not been there.

The "Coolaid" is a reference to the Jonestown massacre where people dies from drinking poisoned Kool-aid (how its supposed to be spelled). They stopped thinking for themselves and follower the herd right to their doom... Kinda like the Linux herd is following the megacorps into the Windows way of thinking and designing software. Its not really a reference to software but to human behavior.

ALSA is the name of the kernel driver (framework) AND the userspace backend (libasound.so). It's perfectly reasonably to link against the userspace library of ALSA if you want to play back some noise to the user. huh? libsdl and libsdl2 are one of the few libraries that have a very good track record with maintaining backward compatibility in my experience. I don't recall ever having any troubles with using my systems libsdl.
What known breakage are you referring to ?

The whole selling point of SDL is that it is a simple abstraction layer allowing the application developer to ignore all the particular details of numerous lower level audio, input and windowing backends. Shipping a sdl library that forces a particular backend dependency on the user seems rather counter intuitive in that context ;)

imo SDL is the prime example for a library where you tell the user to install it from the distribution instead of bundling it.

It means being elite-grade proud about building stuff from matches. Its respectable, but nothing special.

Yeah, I have zero problems, thanks. I do not use Gnome either.
If I would still have 486 around, I would indeed use Openbox, thank you!

Yes, people refused to use HAL preferring to load kernel modules per-hand at boot. How is it different from editing asound.conf per-hand just to make audio work?

Pulse scheduling method exposes defective ALSA drivers.
Pulse - OK. Alsa - NEEDFIX.
Whats so hard to comprehend here?

It means to have irrational self-reassurance in validity of own actions, instead of using brains and eyes, yes.
Since when "less is more" - a windows way of thinking?
Is it bad to have machine save your time, aint machines designed for that, so you can "do more with less" ?
Its perfectly fine to have ability of manual control, but manual control should not be requirement or seen as "advantage" by itself alone (matchstick elitism of textfile voodoo).

Libasound (alsa-lib) unrelated to ALSA, its merely a legacy wrapper to manage virtual interfaces, which appeared during the "14+1 mixer era" to determine which mixer to use(that is, before Pulse came and replaced those 14).
Its outdated, overengineered and wrong on many levels:
a legacy application calling alsa-lib to find and call the default device, which would then call 14+1 of possible (legacy) mixers, which should then do mixing work and link back into ... Alsa;
where a modern application calls pulse-simple.so that sinks into locally running daemon, which mixes and routes (on localhost or remote) into driver backend (ALSA). Its trivial to see that modern way is much more straight forward and complete.

What really possibly needed is ability to either execute Pulse or Alsa(dmix) for application, which can be solved by Pulse providing own simplified version of alsa-lib - but then there is question of why would anyone sink into Alsa directly?

This is exactly because the reality is much more complex than:
Noises can be of different volumes, bit-rates, frequences, coming from different sources and going into different destinations, which architectures can drastically vary often lacking hardware mixers. TL;DR what "Audio Server" is for. This was the reason of 14+1 sound mixers, reason why Pulse appeared and why it unified all these mixers into one standard, so it can finally just play noise properly.

Thus I don't really understand why would anyone want to wake the zombie (dmix) by frankenstein'ing parts to it to make it look like an "alternative" to Pulse (especially under the motto "I can edit text files"), when the "alternative" is most certainly not needed - unless one wants 14+1 situation to flashback with half-working half-finished solutions that half-talk to each other. The audio server is here, it has automagic, its very configurable for any taste, just use it. And if it does not work or work not as desired, fire a bugreport.
In a rare scenario when local system really comes to dialog between one sound card and one application (like embedded) bypassing audio server is fine, this is probably the only case when above mentioned application interface switcher pays off. But this is a TODO and its not the alsa-lib in its current form.

Yes, but its not what proprietary devs do. They do own stuff and then input breaks or things segfault.

We could go on but you obviously do not have a clue and just want to bitch.

" If I would still have 486 around, I would indeed use Openbox, thank you!"

Pulseaudio works for many people and is less than ideal for others.

No reason to get upset over it, especially when the game plays its audio through SDL that it is dynamically linked to. Just substitute with one that supports your sound system. If there's been ABI breakage (apart from the obvious SDL1/SDL2) it hasn't affected me and I'm pretty sure I've ran a game that originally only had OSS support like this, an approach that should still work when both ALSA and Pulseaudio in turn are history.

For this reason I was disappointed to see Thimbleweed Park link SDL statically. The SDL2 license allows for this, but it's discouraged for pretty much this very reason.

All this said, wouldn't proper ALSA support for the developers just be a matter of configuring their SDL with --enable-alsa? I don't think this would add any extra requirements even, because ALSA will be there anyway. And then everyone would be happy. Worth suggesting to them?

EDIT: On second thought, it would still require pulseaudio, which was the problem. Myself I run mostly ALSA on emu10k1, but also keep Pulseaudio running for all the software that needs it.

Thimbleweed Park run smoothly with ALSA. I did not encounter any problem. :-)