Unable to launch on aarch64 (arm) linux

[DCNick3]

Describe the bug: Attempt to launch om aarch64 ubuntu linux does not succeed. What have failed:

• osu failed to load acodec-related libraries, as my distribution does not have libavformat.so (and others) symlinked to actual library, only libavcodec.so.58 is symlinked (for a concrete ABI version). Adding symlinks fixes the issue
• after adding symlinks to avcodec-related libraries errors on video decoding appeared in the log (shown below)
• osu failed to load libstbi.so (probably due to lack of version compiled for aarch64)
• osu stalled while loading with 100% cpu load. As runtime.log stops at Loading SocialOverlay..., I guess that it does cause the issue

Screenshots or videos showing encountered issue:

osu! stalls in this state:

osu!lazer version:

2019.1205.0

Logs:

Video decoding errors:

[runtime:verbose] 2019-12-12 12:53:18: at osu.Framework.Graphics.Video.VideoDecoder.prepareDecoding()
[runtime:verbose] 2019-12-12 12:53:18: at osu.Framework.Graphics.Video.VideoDecoder.StartDecoding()

runtime.log

[enoslayd]

Do you have system-wide ffmpeg installed?

[smoogipoo]

osu failed to load libsbi.so (probably due to lack of version compiled for aarch64)

does this cause a crash for you?

[mcendu]

AArch64 is not a typo. The name is used to refer to 64-bit ARM CPUs.

[peppy]

Oh. That makes it a bit more obvious why it's crashing. We have not even considered support for that platform.

[DCNick3]

Do you have system-wide ffmpeg installed?

Yes

does this cause a crash for you?

No, it does not crash. It's just one of (obvious) errors found in logs. What happens is that osu! stalls at black screen with "development build" text at the bottom, eating 100% of one cpu core.

I don't know what causes it, but, as it looks like from #7062, inability to find libstbi.so, which is a native part of StbiSharp, is not fatal.

Most probably the problem is inside Loading SocialOverlay..., as it is the last thing you can see in log.

[bdach]

Does the game run if you switch from IntroSequence = Triangles to IntroSequence = Circles in ~/.local/share/osu/game.ini?

If not, it is likely that stall requires debugging with the actual hardware. We could try to get a trace from you since apparently there are ways to do so on .NET Core 3.0, but it might be easier if you just profiled on your own (if you can, that is).

[DCNick3]

Will check it after several days, thank you.

About the profiling thing - what is the idea? Should I just slap some breakpoints and see what works and what does not? Or should I check the dotnet trace?

[bdach]

From what I understand what you do is dotnet trace collect -p [PID] (see random unchecked source). Unfortunately there doesn't seem to be a way to start collecting a trace when the process spawns, so you're going to have to be quick on the draw or get a script going probably.

[DCNick3]

Does the game run if you switch from IntroSequence = Triangles to IntroSequence = Circles in ~/.local/share/osu/game.ini?

The funny thing is that the game.ini is not even created, so looks like the startup fails earlier.

[DCNick3]

Adding the IntroSequence = Circles to ~/.local/share/osu/game.ini made the greeting play successfully, but the game still stalls at Loading SocialOverlay.... Will proceed to tracing.

[DCNick3]

I've done it and, after spending some time, I can say that there probably is an audio thread lockup happening in osu.Framework.Audio.Track.TrackBass.StartAsync, inside the lambda, that goes into external code (that is, libbass):

To further confirm it I would need to do some patched to osu.Framework. How could one do so and link osu! against that patched framework?

Also, I'm attaching a trace in case someone wants to dig deeper: trace.nettrace.zip

[LanTenDragon]

@DCNick3 See the framework's wiki https://github.com/ppy/osu-framework/wiki/Testing-local-framework-checkout-with-other-projects

[DCNick3]

Thanks, will continue to investigate

[DCNick3]

By adding logging calls, I've found that the control goes to Bass.ChannelPlay in osu.Framework.Audio.Track.TrackBass.startInternal and never returns. So, this is where the lockup happens. Don't really know what should I do with it next...

[peppy]

You'd probably want to start by finding and adding the correct bass library files for your platform.

[DCNick3]

Well, I have done it at the beginning, getting them from https://www.un4seen.com/forum/?topic=13804.0

The thing is that the library does work to some extent (the linking is done fine). Also the "circles" sound is played too, but the ChannelPlay routine never returns (previous calls are executed successfully). I think this might be a problem with ABI, but I'm not entirely sure, as I would expect a crash or some "junk" values as a return value...

[HopeBaron]

I can confirm the same issue on my machine with arch64 but I fixed this by changing the audio source to Pulse Audio Server which I use for my setup. Thought it's worth mentioning

[squidink7]

Sorry to necro-bump (if that's even a thing here), but I just attempted to build osu! on my Raspberry Pi 4, and thought I'd leave some notes for anyone else who wanted to undertake this challenge. Since the other comments in this issue, osu! switched to realm as the database, which requires a native librealm-wrappers.so library. This doesn't come built for arm64 by default, and I had to build the realm-dotnet repository from source in order to get it to work. Unfortunately for whatever reason, arch Linux's version of OpenSSL didn't contain the files necessary for this to build, and that library didn't contain a prebuilt version of it to automatically download like it does x64. To avoid myself the pain of having to compile a library for compiling library for compiling this game, I just grabbed the Debian package and added the necessary files. After I got it all worked out, eventually it produced the realm-wrappers library which I added to the native libs folder along with the bass libraries mentioned above. After all this osu! now works, albeit very slowly (but that's just the power of the PI's gpu and outdated OpenGL).

[TailsFanLOL]

Yo, anyone still here? I am trying to get osu! running on Acer Chromebook Tab 10, which is currently running PostMarketOS. This is MUSL/Linux, so I don't see how it is any different from Android (a supported platform). However, running it thru dotnet produces no logs at all. It does run in WayDroid, however only at like 17FPS in the menus, I just wanna try running it natively and see if that works.

[squidink7]

I don't currently have an arm device available to test anymore but I have helped someone recently get it to work so it can be done if you're committed. Since my previous comment, realm-dotnet includes everything necessary to work on arm, so if you add the bass libraries that should be enough to get it to compile.

[bdach]

If anything I suspect musl may be the issue here. We don't care but I believe our dependencies may generally assume glibc.

[TailsFanLOL]

so if you add the bass libraries that should be enough to get it to compile.

It does compile, it just doesn't run.