Sound issues with Android

[m...@killerbeesoftware.com]

This morning Android builds seem to be crashing whenever a sound is played. I have an apk from two days ago where the sound is playing fine. apk's built today for android crash.

 

It is possible I have done something wrong, but I made sure and rolled back all of my changes to that prior date and the sound still is causing a crash. Also ran a small test app which just plays a sound and get the same result.

 

When the sound starts to play (it is played), the dialog comes up and says the App has stopped suddenly, and the only option is a forced exit.

 

Same source build on iOS works as it should.

 

 

 

 

[Shai Almog]

Do you have a stack track for this from DDMS?
We made some bug fixes but I'm not sure which one might be causing this?

[m...@killerbeesoftware.com]

I am afraid I get nothing but the dialog saying the program has stopped unexpectedly. My os is 2.3 and a user reported it to me with 4.1.2 The 4.1.2 user does not see the dialog - it goes straight to the tray.

[m...@killerbeesoftware.com]

 

I am sorry, I have never had to use DDMS - misunderstood what it was. Will see if I can get it going. 

[m...@killerbeesoftware.com]

Does this help:

 

11-22 16:32:50.195: W/System.err(13431): Play/s_warn.mp3
11-22 16:32:50.203: D/AudioHardwareALSA(1415): Preparing the device
11-22 16:32:50.210: W/dalvikvm(13431): threadid=10: thread exiting with uncaught exception (group=0x40018560)
11-22 16:32:50.210: E/liblog(1525): failed to call dumpstate
11-22 16:32:50.210: E/AndroidRuntime(13431): FATAL EXCEPTION: Thread-11
11-22 16:32:50.210: E/AndroidRuntime(13431): java.lang.SecurityException: Neither user 10065 nor current process has android.permission.READ_PHONE_STATE.
11-22 16:32:50.210: E/AndroidRuntime(13431):  at android.os.Parcel.readException(Parcel.java:1322)
11-22 16:32:50.210: E/AndroidRuntime(13431):  at android.os.Parcel.readException(Parcel.java:1276)
11-22 16:32:50.210: E/AndroidRuntime(13431):  at com.android.internal.telephony.ITelephonyRegistry$Stub$Proxy.listen(ITelephonyRegistry.java:201)
11-22 16:32:50.210: E/AndroidRuntime(13431):  at android.telephony.TelephonyManager.listen(TelephonyManager.java:963)
11-22 16:32:50.210: E/AndroidRuntime(13431):  at com.codename1.impl.android.Audio$4.run(Audio.java:324)
11-22 16:32:50.210: E/AndroidRuntime(13431):  at java.lang.Thread.run(Thread.java:1019)
11-22 16:32:50.234: W/ActivityManager(1525):   Force finishing activity com.kbs.EDMEApp/.EDMEAppStub
11-22 16:32:50.250: I/WindowManager(1525): Setting rotation to 0, animFlags=1

 

 

[m...@killerbeesoftware.com]

I checked the AndroidManifest.xml, and it does not specify that permission.

[m...@killerbeesoftware.com]

  private void addToCurrentPlaying() {
        if (currentPlayingAudio.size() == 0) {
            new Thread(new Runnable() {

                public void run() {
                    Looper.prepare();
                    TelephonyManager mgr = (TelephonyManager)activity.getSystemService(TELEPHONY_SERVICE);
                    if (mgr != null) {
                        phoneStateListener = new PhoneStateListener() {

                            @Override
                            public void onCallStateChanged(int state, String incomingNumber) {
                                if (state == TelephonyManager.CALL_STATE_RINGING) {
                                    //Incoming call: Pause music
                                    for (int i = 0; i < currentPlayingAudio.size(); i++) {
                                        Audio m = (Audio) currentPlayingAudio.elementAt(i);
                                        if (m.isPlaying() && m.player != null) {
                                            m.player.pause();
                                        }
                                    }
                                } else if (state == TelephonyManager.CALL_STATE_IDLE) {
                                    //Not in call: Play music
                                    for (int i = 0; i < currentPlayingAudio.size(); i++) {
                                        Audio m = (Audio) currentPlayingAudio.elementAt(i);
                                        if (!m.isPlaying() && m.player != null) {
                                            m.player.start();
                                        }
                                    }
                                } else if (state == TelephonyManager.CALL_STATE_OFFHOOK) {
                                    //A call is dialing, active or on hold
                                    for (int i = 0; i < currentPlayingAudio.size(); i++) {
                                        Audio m = (Audio) currentPlayingAudio.elementAt(i);
                                        if (m.isPlaying() && m.player != null) {
                                            m.player.pause();
                                        }
                                    }
                                }
                                super.onCallStateChanged(state, incomingNumber);
                            }

                        };
                        mgr.listen(phoneStateListener, PhoneStateListener.LISTEN_CALL_STATE);  <== Exception Line 324
                    }
                    Looper.loop();
                }
            }).start();
        }
        currentPlayingAudio.add(this);
    }
 

[Chen Fishbein]

thanks, I will fix this.

in the meantime you can locally patch this by adding a call to:

Display.getInstance().getUdid();

(It will trigger the addition of the missing permission,)

[m...@killerbeesoftware.com]

Looks like Shai's posts have disappeared, but I did do a build and the sound is working. Just wanted to note that DDMS is still showing that stack trace error. I assume this is expected?

 

[Shai Almog]

I deleted them to avoid confusion. You are seeing a temporary workaround I made. After the next server update you will see an additional permission added which it seems is just unavoidable in Android.

[m...@killerbeesoftware.com]

 

 

 

I noticed some crashing with my app while testing, so I have been running my test program, which plays a sound over and over. 

 

After a few minutes, I can get an exit with:

 

11-23 21:17:02.492: A/Looper(27878): Could not create wake pipe.  errno=24

 

I am definitely calling cleanup after each play. Definitely was not having this issue before.

 

 

[m...@killerbeesoftware.com]

I put a counter in the program, and it is consistently failing after 245 sound plays on my device. 

[Shai Almog]

Is there any more information besides the broken pipe message in verbose mode?

[m...@killerbeesoftware.com]

Attached. Just made this run. Line 346 is the Looper Line.  The line just before it:

 11-24 00:11:00.125: I/System.out(8633): Plays_warn.mp3 246  is my App wit 246 being the count of sounds played.

[m...@killerbeesoftware.com]

Ok, It appears I am getting two threads produced for every sound.  I looked into the threads after seeing the Audio.java code:

private void addToCurrentPlaying() {

        if (currentPlayingAudio.size() == 0) {

            new Thread(new Runnable() {

public void run() {

                    try {

                        Looper.prepare();

...

                        Looper.loop();

                    } catch(Throwable t) {

                        t.printStackTrace();

                    }

                }

            }).start();

        }

        currentPlayingAudio.add(this);

    }

    private void removeFromCurrentPlaying() {

        currentPlayingAudio.remove(this);

        if (currentPlayingAudio.size() == 0) {

            new Thread(new Runnable() {

                public void run() {

                    Looper.prepare();

...

                    Looper.loop();

                }

            }).start();

        }

    }

    

I do not see a Looper.quit() call anywhere, so they will go on forever,,, and these new threads in DDMS are looking like this:

  at android.os.MessageQueue.nativePollOnce(Native Method)

  at android.os.MessageQueue.next(MessageQueue.java:119)

  at android.os.Looper.loop(Looper.java:117)

  at com.codename1.impl.android.Audio$5.run(Audio.java:348)

  at java.lang.Thread.run(Thread.java:1019)

  

  I think what is happening is as the currentPlayingAudio Vector oscillates between 1 element and none a thread is created that never goes away. Does that make sense to you? the threads are definitely appearing in DDMS as the test runs.Each one could be taking up one (or more) FD.

[m...@killerbeesoftware.com]

and at 245 sounds played I have exactly 500 threads going in the app.

[Chen Fishbein]

Thanks, that make perfect sense.

I will fix this.

[m...@killerbeesoftware.com]

I saw an update come in on svn.

 

There is one other observation I wanted to make in regards to the android build and create media via uri, I do not know if it is related to the current issue -

 

In the Android build, the completion runnable was running on a thread called "main". NOT the EDT.

 

On the iphone, the completion Runnable fired on the EDT.

 

on the SE port, the runnable does not seem to fire and the threads hang out.

 

I had been using the Runnable to do cleanup type stuff, and on android I would occasionally get an IllegalStateException when isPlaying was called. when I stopped making those calls in the Runnable and just touched a switch the EDT would deal with later, , that occasional error has gone away.

 

 

[m...@killerbeesoftware.com]

I am sorry, I made a mistake in regards tot the SE port - as my logging was turned off.

 

The SE port is fired on something called the "Task Thread", again not the EDT.

 

I think my question here is - are the use of different threads intentional?

 

[Shai Almog]

We'll fix those. Everything should always be invoked on the EDT unless explicitly stated otherwise.

[m...@killerbeesoftware.com]

I am sure this is related to the changes that went in.  Now getting an uncaught exception in the main loop. I did file issue 972 on this. Please let me know when this can be fixed up. Thanks.

 

11-26 10:08:31.585: E/wlg(9242): MediaPlayer.start()  mIsStream = false
11-26 10:08:31.601: E/wlg(9242): MediaPlayer.start()  mIsStream = false
11-26 10:08:31.601: D/AndroidRuntime(9242): Shutting down VM
11-26 10:08:31.601: W/dalvikvm(9242): threadid=1: thread exiting with uncaught exception (group=0x40018560)
11-26 10:08:31.609: E/liblog(1525): failed to call dumpstate
11-26 10:08:31.609: E/AndroidRuntime(9242): FATAL EXCEPTION: main
11-26 10:08:31.609: E/AndroidRuntime(9242): java.lang.IllegalStateException
11-26 10:08:31.609: E/AndroidRuntime(9242):  at android.media.MediaPlayer._start(Native Method)
11-26 10:08:31.609: E/AndroidRuntime(9242):  at android.media.MediaPlayer.start(MediaPlayer.java:1073)
11-26 10:08:31.609: E/AndroidRuntime(9242):  at com.codename1.impl.android.Audio$4$1.onCallStateChanged(Audio.java:311)
11-26 10:08:31.609: E/AndroidRuntime(9242):  at android.telephony.PhoneStateListener$2.handleMessage(PhoneStateListener.java:319)
11-26 10:08:31.609: E/AndroidRuntime(9242):  at android.os.Handler.dispatchMessage(Handler.java:99)
11-26 10:08:31.609: E/AndroidRuntime(9242):  at android.os.Looper.loop(Looper.java:130)
11-26 10:08:31.609: E/AndroidRuntime(9242):  at android.app.ActivityThread.main(ActivityThread.java:3683)
11-26 10:08:31.609: E/AndroidRuntime(9242):  at java.lang.reflect.Method.invokeNative(Native Method)
11-26 10:08:31.609: E/AndroidRuntime(9242):  at java.lang.reflect.Method.invoke(Method.java:507)
11-26 10:08:31.609: E/AndroidRuntime(9242):  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)
11-26 10:08:31.609: E/AndroidRuntime(9242):  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
11-26 10:08:31.609: E/AndroidRuntime(9242):  at dalvik.system.NativeStart.main(Native Method)
11-26 10:08:31.609: W/ActivityManager(1525):   Force finishing activity com.kbs.EDMEApp/.EDMEAppStub
11-26 10:08:31.726: D/SurfaceFlinger(1525): Layer[2f48f0]:: Tile format buffer w[320] h[288] f[1] v[0x45e1f000] p[0x9b763000] sz[368640]

 

 

 

[Shai Almog]

This will probably take a couple of days to update since we have quite a few changes. I see Chen fixed it in SVN but the server update won't be trivial.

[m...@killerbeesoftware.com]

On Tuesday, November 26, 2013 1:07:35 PM UTC-6, Shai Almog wrote:

This will probably take a couple of days to update since we have quite a few changes. I see Chen fixed it in SVN but the server update won't be trivial.

 

Understood. Thank you. 

[Shai Almog]

We ended up fixing it last night because of the other issues mentioned.