Help needed with Android port of OpenMSX!

Page 3/4
1 | 2 | | 4

By sdsnatcher73

Paragon (1095)

sdsnatcher73's picture

31-08-2020, 18:30

Manuel wrote:

As you know, we can also discuss on IRC about how to implement the controls. IMHO, we should use the multi-touch events from SDL2 and make them available in openMSX. Then make them available to Tcl as well and then probably the controls could be made in Tcl with the OSD elements. (Similar to the OSD keyboard, which is a little hard to use because of the missing support for multitouch.)

How much of this would help migrating the openDingux build to SDL2? How to even get started on building for openDingux?

By Manuel

Ascended (16864)

Manuel's picture

31-08-2020, 19:20

OD needs an updated toolchain to build, but otherwise should be working still.

By wbahnassi

Expert (112)

wbahnassi's picture

05-09-2020, 16:28

Alright, update of the week:

  • The two remaining bugs have been fixed
  • The mouse coordinate misalignment bug is caused by bad SDL behavior. They should really fix this. Basically coordinates received through events are filtered by the rendering sub-system and the coordinates get adjusted to the window's dimensions, giving you good numbers. However, SDL_GetMouseState doesn't go through this filter, hence just returns raw values mapped to the actual device dimensions. I've stopped using SDL_GetMouseState and switched to caching the mouse position from the event system instead.
  • env(HOME) isn't defined on Android, so Tcl main menu fails to initialize. I manually set this path to the openMSX user directory on Android only. I hope this is fine.
  • Fixed some other minor stuff.
  • Now I'm able to get openMSX to operate and open ROMs, but no way to control the games since there are no OSD controls yet. This is the next step.
  • Bad news, as I got ROMs to play, I noticed the audio delay that instigated this whole SDL2 effort on Android is still there. It's noticeable. Since SDL2 didn't improve the situation here, this bug should theoretically be solvable on both SDL2 and the previous Android version of openMSX. In other words, if someone wants to jump in and fix this bug, you can start fixing it even on the old version.

For reference, the branch I'm working on is here: https://github.com/wbahnassi-if/openMSX/tree/sdl2-android
If any one wants to try it let me know and I can send the instructions (the build scripts I made are still not production-ready as they have lots of hard-coded stuff).

That's it for this week.
Cheers!

By tfh

Prophet (2377)

tfh's picture

05-09-2020, 17:29

Thanks for the update and your effort on reviving OpenMSX for Android!

By Retrofan

Paragon (1253)

Retrofan's picture

08-09-2020, 02:45

wbahnassi wrote:

[*]Bad news, as I got ROMs to play, I noticed the audio delay that instigated this whole SDL2 effort on Android is still there. It's noticeable. Since SDL2 didn't improve the situation here, this bug should theoretically be solvable on both SDL2 and the previous Android version of openMSX. In other words, if someone wants to jump in and fix this bug, you can start fixing it even on the old version.

That's indeed bad news, but maybe Google Oboe can overcome this? It seems there are issues with the SDL sound mixer as I read on the Internet. Please also try to change sample frequency to 66150. Hardware accelleration should also be turned off for audio.

But great job so far with SDL2!

By sdsnatcher73

Paragon (1095)

sdsnatcher73's picture

08-09-2020, 05:53

From what I read on the 66150 link above it seems SDL_Mixer is just not very good, especially noticeable on Android. Another user switched to openAL which is also cross platform (Mao it could be a generic switch for all platforms targeted by openMSX.

By wbahnassi

Expert (112)

wbahnassi's picture

08-09-2020, 14:33

I haven't investigated the sound issue. On Knightmare, I estimate about 400ms-500ms delay between the event and the sound (e.g. hitting a box and hearing the cling). IMO if it was Android in genereal I would have seen 500ms delay between touch on the keyboard and the click sound I get in the entire system. Plus, there are numerous musical apps, and there is no way those would function with such a huge delay, so the blame has to be in SDL or our code.

By Manuel

Ascended (16864)

Manuel's picture

09-09-2020, 14:31

I asked the SDL devs and they asked whether we tried both available backends. The easiest way to switch is to edit src/audio/SDL_audio.c.
There are both: openslES_bootstrap and ANDROIDAUDIO_bootstrap in the list. Comment 1 out, then the other.

Can you try that, wbahnassi?

By Manuel

Ascended (16864)

Manuel's picture

09-09-2020, 16:42

More hints I got in the #SDL IRC channel:
Quibus, may you can also try to set the thread priority of android
what you can try is to use the ANDROIDAUDIO bootstrap
it has "android.os.Process.THREAD_PRIORITY_AUDIO" in SDLAudioManager.java
you can change it to: THREAD_PRIORITY_URGENT_AUDIO
(See: THREAD_PRIORITY_URGENT_AUDIO )
https://developer.android.com/reference/android/os/Process
just to test if that helps ..
maybe this priority would apply both for openSLES and ANDROIDAUDIO
cause, it's called in SDL\_audio.c via Android_JNI_AudioSetThreadPriority()
and also, you can look at: android.hardware.audio.pro indicates a continuous round-trip latency of 20 ms or less.
oops: https://developer.android.com/ndk/guides/audio/audio-latency
check the feature of your device: getPackageManager().hasSystemFeature(PackageManager.FEATURE_AUDIO_LOW_LATENCY);
getPackageManager().hasSystemFeature(PackageManager.FEATURE_AUDIO_PRO);
check the audio buffer queue ..

Can you tell me whether that helps?

By wbahnassi

Expert (112)

wbahnassi's picture

09-09-2020, 17:45

I'll give those suggestions a try Manuel and let you know. Stay tuned, and thanks for the support!

Page 3/4
1 | 2 | | 4