AssetManager Not working on Android

Anything libgdx related goes here!

AssetManager Not working on Android

Postby Crazy C » Mon Nov 04, 2019 7:55 pm

In my create method I create a new AssetManager instance, then I use AssetManager.load, then AssetManager.finishLoading, then AssetManager.get then Sound.loop to load and Play a small Sound in Loop Mode. The program always crashes.
When I use the Gdx.audio.newSound Variant and wait half of a Second before playing the Sound everything works ok.
Has Someone the Same Problem.
I didn't Post the Code because using AssetManager is too easy.
Crazy C
 
Posts: 5
Joined: Sun Feb 03, 2019 9:19 am
Location: Germany, Hannover

Re: AssetManager Not working on Android

Postby Crazy C » Tue Nov 05, 2019 7:39 pm

I added after the AssetManager.finishLoading method a few lines to let the program wait for half of a second, now the sound ist being played like with Gdx.audio.newSound. Why then is finishLoading said to return only after it has loaded all assets? In my case this is simply not true.
Crazy C
 
Posts: 5
Joined: Sun Feb 03, 2019 9:19 am
Location: Germany, Hannover

Re: AssetManager Not working on Android

Postby shatterblast » Wed Nov 06, 2019 12:35 am

It has do with threading somewhat. Some of the simplified features of LibGDX will use a second thread from a ThreadPool object. All of your assets "load" when you declare them for your AssetManager. When LibGDX starts up for your software, it immediately loads everything before you see something on screen. This runs slightly different for Music objects, since they "stream" instead of "load".

Basically, if your software tries to load two different Sound objects at the same exact time, then it can cause a problem for the second thread. This is primarily why they should associate with Listener objects. If you have an Actor, like say for a scrolling game, then a typical practice involves tying a Listener to certain events, which might include "jumping" or "dashing" for instance. Since Actors tend to act like different "threads" in a sense, even on the same thread, Sound objects behave in a somewhat safer manner. Actually, there is a priority queue of sorts with events in LibGDX, similar to how a Queue object may work. Because of this, Sound objects do not fire at the same exact time, since only one Sound can fire off for a specified event in the queue per render cycle. That would be the reason to put your code for playing a Sound object into the method of a Listener that pays attention to the events of an Actor.

Of course, events can behave strangely, too. I suggest approaching those conservatively and taking your time when implementing one. Having too many events causes either slow down or something difficult to trace when a Sound doesn't fire like it should.
shatterblast
 
Posts: 498
Joined: Sun Jul 06, 2014 1:14 pm


Return to Libgdx

Who is online

Users browsing this forum: Google [Bot], hais, MSN [Bot] and 1 guest