Issue: Sound rapidly dying on Linux system(s)

[Agetian]

Just recently I had a chance to try out the latest builds of Forge on a Linux system - it is a decent installation that works, bar some minor video issues, nearly perfectly, with good sound setup (so it's most likely not a system issue). Forge runs on it perfectly fine except for one thing - the sound system doesn't work correctly for some weird reason. That is, it starts fine, then it quickly starts dying as less and less sounds get played. It seems that the first time the sound is played, it's played just fine, but the next time it's supposed to be played, it's either not played at all or "cuts off". Even if it does play the second time, it most certainly dies the next time after that. Soon afterwards (in 3-4 turns), almost no sounds play at all in Forge. I haven't been able to remedy this in any way or even understand what I'd possibly need to change in the code in order to make it work correctly.

The Linux system is question is running Linux Mint 14 with the standard OpenJDK 7. I assume it's more or less the same as the standard Oracle JDK minus some (very few) remaining proprietary packages. Forge runs flawlessly otherwise, with no other apparent issues.

The questions are:
1) Are any other of you running Forge on Linux experiencing the same thing?
2) Is anyone in the know as to what can potentially cause this and what should be done to fix it?

Thanks in advance for help.

- Agetian

[Agetian]

I investigated the issue and came to a conclusion that the implementation of the sound cache is what seemingly makes the sound system die on Linux (by the way, tested on two non-virtual Linux systems, both Mint (13 and 14), and one virtual system based on Arch). The following makes the sound behave better for a while (the sounds don't disappear one by one), but eventually the game runs out of audio resources or something and throws a "Unable to obtain a line" exception, after which it goes fully mute:

Code: Select all

# This patch file was generated by NetBeans IDE
# It uses platform neutral UTF-8 encoding and \n newlines.
--- Base (BASE)
+++ Locally Modified (Based On LOCAL)
@@ -36,11 +36,8 @@
         }
 
         IAudioClip clip = loadedClips.get(type);
-        if (null == clip) { // cache miss
             String resource = type.getResourceFileName();
             clip = AudioClip.fileExists(resource) ? new AudioClip(resource) : emptySound;
-            loadedClips.put(type, clip);
-        }
         return clip;
     }
 
@@ -55,11 +52,7 @@
             return emptySound;
         }
 
-        IAudioClip clip = loadedScriptClips.get(fileName);
-        if (null == clip) { // cache miss
-            clip = AudioClip.fileExists(fileName) ? new AudioClip(fileName) : emptySound;
-            loadedScriptClips.put(fileName, clip);
-        }
+        IAudioClip clip = AudioClip.fileExists(fileName) ? new AudioClip(fileName) : emptySound;
         return clip;
     }


Please help me determine what can be done here - on the one hand, applying the change above doesn't fully solve the problem (the game eventually runs out of resources and goes mute anyway), but on the other hand, it does at least show the potential location of the issue. :\

P.S. The exact exception that occurs when applying the change above is:

Code: Select all

Error initializing sound system: javax.sound.sampled.LineUnavailableException: unable to obtain a line
Apr 04, 2013 2:55:04 PM com.google.common.eventbus.EventBus dispatch
SEVERE: Could not dispatch event: forge.game.event.LandPlayedEvent@4e3a061b to handler [wrapper public void forge.sound.SoundSystem.receiveEvent(forge.game.event.Event)]
java.lang.reflect.InvocationTargetException
        at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:69)
        at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45)
        at com.google.common.eventbus.EventBus.dispatch(EventBus.java:302)
        at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:285)
        at com.google.common.eventbus.EventBus.post(EventBus.java:249)
        at forge.game.player.Player.playLand(Player.java:1764)
        at forge.game.ai.AiController.playLands(AiController.java:849)
        at forge.game.ai.AiController.onPriorityRecieved(AiController.java:805)
        at forge.game.ai.AiInputCommon$1.run(AiInputCommon.java:74)
        at forge.FThreads$1.run(FThreads.java:102)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:722)
Caused by: java.util.MissingResourceException: Sound clip failed to load
        at forge.sound.AudioClip.<init>(AudioClip.java:76)
        at forge.sound.SoundSystem.fetchResource(SoundSystem.java:40)
        at forge.sound.SoundSystem.play(SoundSystem.java:63)
        at forge.sound.SoundSystem.receiveEvent(SoundSystem.java:141)
        ... 16 more


- Agetian

[Max mtg]

I thought of a different API
http://search.maven.org/#artifactdetail ... 0-rc11|jar

[Agetian]

That looks interesting, Max! Do you know if it would incur a big overhead as a Forge dependency (I mean the size)? Also, do you know how to plug it in to the Forge source code (I know we're using a lot of Maven repository libraries there, but I haven't really used that repository myself yet).

- Agetian

[Max mtg]

Integration is easy:
add code below to pom.xml where similiar entries are listed:

Code: Select all

<dependency>
    <groupId>org.jogamp.joal</groupId>
    <artifactId>joal-main</artifactId>
    <version>2.0-rc11</version>
</dependency>

Don't know about overhead - never tried a build with it. At a later time we might use their jogl (Java OpenGL) library to build a client with 3d cards and effects.

[Agetian]

Ok, thanks for help! I'm going to look into it!

- Agetian

[myk]

for what it's worth, I run Forge on Linux all the time and haven't had any issues. It's running Gentoo. It has PulseAudio 2.1 as the primary sound API, running with alsa-plugins 1.0.25 (which I presume Java is using to shuttle sound to pulseaudio). The kernel is 3.7.10.

[Agetian]

@ myk: Hmm, interesting! Thanks for the input! None of my linux systems is as new as 3.7.10, the latest kernel I'm running is 3.5-something, and I assume both of the other systems I experimented with were actually older. I wonder if this is some issue with either the kernel, or PulseAudio ("we are not surprised" (C)), or maybe even OpenJDK that got fixed over time in the newer revisions?... I got to find myself a newer Linux system to experiment with. Anyhoo, I'll also look into changing over to a better API so that there won't be any issues anywhere, just need a little time to experiment and tweak things.

- Agetian

[Agetian]

I investigated the issue a little more and it seems like it's a rather common issue with the standard Java Sound API on certain Linux configurations that has to do with it not playing well with Pulseaudio on some systems. Looks like we might look into changing an API. I looked at JOAL and it seems like it needs some native library bindings which are not readily available in most repositories, so it might involve more hassle with compilation or download of third party libraries at least on Linux, not sure about Windows. Would LWJGL be an option? I know it's used in several Java games, it seems lightweight enough, and its libraries are easy to obtain. Is a Maven connection possible and viable for LWJGL?

- Agetian

[friarsol]

I investigated the issue a little more and it seems like it's a rather common issue with the standard Java Sound API on certain Linux configurations that has to do with it not playing well with Pulseaudio on some systems. Looks like we might look into changing an API. I looked at JOAL and it seems like it needs some native library bindings which are not readily available in most repositories, so it might involve more hassle with compilation or download of third party libraries at least on Linux, not sure about Windows. Would LWJGL be an option? I know it's used in several Java games, it seems lightweight enough, and its libraries are easy to obtain. Is a Maven connection possible and viable for LWJGL?

- Agetian

So an old Linux Kernel has issues with the Java libraries, so instead of upgrading the effected Kernel for a very small amount of users, we have to upgrade the whole library that may or may not work for a majority of users?

[Agetian]

@ friarsol: Several points here:

1) This is not a Linux kernel issue, it's primarily a Java issue on Linux (and not even on every Linux, to begin with). To cut a long story short, the Java Sound API is a mess and works inconsistently across systems despite the fact that the rest of (or at least the dominating majority of) the JDK works consistently. In particular, the mechanism it uses does not allow it to release the acquired sound lines consistently and reliably, sometimes it works and sometimes it doesn't. Of course, the Linux sound subsystem is a story in and of itself, but that's a different beast - Java Sound API may cease to work even in scenarios when the sound is otherwise working perfectly in all other (non-Java Sound API dependent) apps, including other Java apps using other libraries such as OpenAL or FMOD.
2) This has nothing to do with how old or new the Linux kernel is. It may cease to work on a brand new kernel, it may work perfectly on a three year old installation. This is much more dependent on a number of other factors (the configuration of PulseAudio used in that particular distro, what mixers are available and which mixer is chosen by the Java Sound API, and how that mixer interoperates with the Java Sound API, the position of the stars on the sky, etc., you know). It's difficult to predict which systems will or will not work, but it doesn't have to necessarily do anything with how old or new the system is.
3) My firm belief is that this issue should be looked into and fixed if possible, even if that means changing the API. Relying on an API that can't work consistently on different systems may somewhat backfire on us in the long run - judging by the threads on the Internet, this particular API has been known to work better and worse on different systems in the past as the time progressed and as the JDK was updated, but it was never particularly reliable and it still isn't. However, changing the API does not have to mean that in the end it "may or may not work for a majority of users" (I've never said that if you take a look). On the contrary, the idea here is to ensure that it works for 99.99%, hopefully for 100%, of our users, no matter whether they are on Windows, Linux, Mac OS X, or another popular operating system that supports Java and has a binding for the API (as such, the API has to be cross-platform, popular, and readily available on all major platforms), without them having to either go through crazy setup procedures or look for the relevant libraries all over the Internet. That's why we're having this discussion here and trying to figure out what would be the safest bet to shoot for. Of course, if we don't find an option like that, we'll stay on the Java Sound API for the time being until a solution can be devised. No rush is intended on this issue - it has to be approached in a careful and conscious manner.
4) It's necessary to stress that changing the API to anything except the built-in JDK Java Sound API *does* introduce an extra dependency to Forge. As such, it is of utmost importance that if it's done that this dependency is lightweight enough, does not cause a large overhead on either the size or the memory usage of the project, is cross-platform, and is easy to either package with Forge or at least install in a hassle-free manner on all popular operating systems.

- Agetian

[friarsol]

Well, you just said "certain Linux configurations" and since you were talking about it possibly having to do with your kernel, that's the only reason I thought that's what you meant. You weren't very specific, so it did indeed sound like an issue. Honestly, I mute Forge when I play, so I don't have any strong concerns about the sound not working. I just want to make sure that if the library needs to change, that the solution isn't causing more issues than it's solving.

[Agetian]

Yeah, I wasn't sure about the kernel since Myk's report indicated that as a possibility, but further investigation showed that it was dependent on other things rather than the kernel revision. And yep, the solution should definitely improve the situation instead of complicating it, that's the only way I'm going to accept it as a solution. I'll keep you guys posted on my further findings! Let me know if you have any further thoughts or ideas, too.

- Agetian

[Agetian]

Ok, nevermind LWJGL, I think JOAL will suffice just great - I tried adding the relevant Maven artifact to the build of a custom project to see what it pulled with itself, as well as to see what it packages into the jar when Maven builds the archive in the "-with-dependencies" mode, and it turns out that it packages both Windows and Linux libraries (potentially Mac OS X too? I don't know how to identify those) into the JAR so there is no issue with that. Also, it is lightweight (more so than the entire LWJGL), the total overhead for pulling in JOAL is under 500 kb (that includes the JOAL classes themselves as well as the packaged dll/so libraries). So far so good, will investigate the API next and come up with a small test project to see if the thing behaves consistently across different systems. Will need someone to test on a Mac OS X system.

- Agetian

[Chris H.]

Ok, nevermind LWJGL, I think JOAL will suffice just great - I tried adding the relevant Maven artifact to the build of a custom project to see what it pulled with itself, as well as to see what it packages into the jar when Maven builds the archive in the "-with-dependencies" mode, and it turns out that it packages both Windows and Linux libraries (potentially Mac OS X too? I don't know how to identify those) into the JAR so there is no issue with that. Also, it is lightweight (more so than the entire LWJGL), the total overhead for pulling in JOAL is under 500 kb (that includes the JOAL classes themselves as well as the packaged dll/so libraries). So far so good, will investigate the API next and come up with a small test project to see if the thing behaves consistently across different systems. Will need someone to test on a Mac OS X system.

- Agetian

 
Sounds like you are getting close to setting up a branch. Myk and/or myself will be able to do a local Maven build for both archives and will be able to test out the Mac version for you.