Incompatible JNA native library on Ubuntu #2
Comments
|
Sorry for the delay in replying. Hmm. I have a very similar setup but I don't get the error about JNA. (I even tried installing libjna-java, adding it to my CLASSPATH, etc., with no warning.) Could you include a dump of "set" (maybe try "bash --posix" and invoke "set" in there to avoid dumping all the auto-complete functions that Ubuntu provides) as well as an "dpkg --get-selections |
|
Hello Ed, Sorry, now it's me who's late responding to your email ... My Java-related packages: tiger:~# dpkg -l | grep java Note that tiger:~# dpkg --get-selections java My typical environment is attached. (I'm running tcsh, but you're probably Hope that helps. Let me know if you'd like me to debug this further. Ralph On Fri, Jun 19, 2015 at 3:37 PM, Ed Swartz notifications@github.com wrote:
|
|
Hi Ralph, I don't think the attachment made it through. You may have to post it I installed all the packages you listed, and still can't reproduce. I BTW, I will be out this week, so no hurry. -- Ed |
|
Hmm, seems like you can only attach images?! Anyway, here's the env: BASH=/bin/bash |
|
And here's the entire console output; maybe I accidentally snipped some important part in the original report: tiger /opt/v9t9 > ./v9t9.sh Failed to open device (/dev/input/event4): Failed to open device /dev/input/event4 (13) Failed to open device (/dev/input/event3): Failed to open device /dev/input/event3 (13) Failed to open device (/dev/input/event2): Failed to open device /dev/input/event2 (13) Failed to open device (/dev/input/event1): Failed to open device /dev/input/event1 (13) Failed to open device (/dev/input/event0): Failed to open device /dev/input/event0 (13) Linux plugin claims to have found 0 controllers There is an incompatible JNA native library installed on this system.
|
|
Now that I'm back and reviewed stuff more carefully, I see that libjna-java in your installation is 3.2.7-4, while the one shipping in V9t9 is 3.4.0, and the one I was trying to reproduce with (i.e. by installing my own version) is 4.1. Anyway, that explains the initial error. I'll put -Djna.nosys in future releases to avoid that. Now that leaves why V9t9 couldn't talk to ALSA. My suspicion is, the default audio playback rate (48000) is not accepted by your card. I will add another -D argument to allow overriding this. It will be in the form "-Dv9t9.sound.rate=44100". |
|
OK, I've uploaded a new version with the fixes mentioned before. Please try them out. |
|
I've tried the new version, but it still doesn't work. I enabled the VMARGS="$VMARGS -Dv9t9.sound.rate=44100" line in v9t9.sh (and I also tried 48000), but the program won't start: tiger /opt/v9t9 > ./v9t9.sh The tail of the log file reads: Note sure what kind of information about my soundcard you would need, but here is: tiger:/# cat /proc/asound/AUDIO/pcm0p/info |
|
Hmm. Well, I'm not even setting the period size (it seems to be done automatically by ALSA). Are you able to build and run the program here: http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_min_8c-example.html#a3? Does it work? It uses essentially the same setup that V9t9 does. If that fails too, I'm going to add a switch to let you use the OpenJDK sound integration. It's improved since I first tried it (when it hardly worked at all) so you may be able to bypass my version. |
|
OK, the new version is up. Use -Dv9t9.sound.java=true to bypass my attempts. And please paste the full v9t9.log if any problems arise, since I added some more info there. |
|
OK, great, it's working now -- even without the -Dv9t9.sound.java=true option. It's a bit choppy, though, i.e. sound (and especially speech) is garbled, and keyboard detection is sluggish (tested with Parsec). CPU utilization never goes above 10%, though. And it's basically the same with -Dv9t9.sound.java=true, except that there is no sound. So, overall it looks fine to me now, although I'm not sure how "smooth" the emulation could be potentially. I'll play around with it some further over the next weeks. Thanks for your help! If you need more information for further investigation just let me know. |
|
OK. Hmm. What are the specs of your computer? (/proc/cpuinfo and glxinfo dumps would be useful.) Especially under Linux, my main dev environment, everything should be working very smoothly. I do recall when testing on Win 7 on an old laptop, sound was a bit choppy, but I thought that was because of Windows. Maybe it's the CPU... You can try toggling the "sound"/speaker button and see if other aspects (like keyboard responsiveness) improve. But please do add v9t9.log at some point, since I can't make any deductions from anecdotes :) |
|
Oh, I should mention -- v9t9.log will be more useful if you also edit v9t9.sh and enable this line: instead of the one in front of it. :) |
|
Well, what is "smooth"? To me, it feels choppy in that the Parsec ship jumps and/or keeps moving after I release the key, and the landscape scrolling looks "wobbly", i.e., the scenery often grows and shrinks during scrolling -- not very profound, but noticeable. There are no such effects in MESS. The speaker button doesn't really affect the choppiness. CPU is with 8 GB RAM, but as I said, CPU utilization never goes above 8% anyway. I've created two debug log files, but I think GitHub won't let me attach them -- can I mail them to you instead? |
|
Ah, I see. I thought you meant the sound was choppy (like stuttering or broken up). Parsec, AFAIR, does have that "physical" effect that the ship will move after you release a key since the keys imply acceleration. I agree about the landscape choppiness. V9t9 tries to avoid eating up CPU by making video updates to the entire screen according to arbitrary host CPU timing, whereas a game like Parsec assumes the video is being updated row-by-row at a given rate and the top row starts being updated in lockstep with the video interrupt, thus giving it time to scroll the landscape "before" the monitor shows the changes. I think MESS tries the row-by-row approach, but it's much more CPU-intensive, and my goal (as you've noticed) is that an emulator asking like an ancient machine will actually use less CPU than a modern machine. ;) That's just a long-winded way to say, I guess I need to pay some more attention to doing that video synchronization more correctly. As for the logs, you could just copy-and-paste them into comments on this issue. |
|
The "inertia" is much more pronounced in v9t9 than in MESS, and I don't think there's inertia for up and down. Additionally, the ship seems to "jump" occasionally, i.e., it looks like some frames are dropped. And yes, the sound is choppy, too, i.e. garbled. :-) But since you implied that my sound setup was somehow unconventional I thought that choppiness was OK. I'll paste the debug log for -Dv9t9.sound.java=true separately; it has 4000 lines, and GitHub says it too long although it isn't. |
|
2015-07-05 14:18:47,100 INFO main - Base emulator V9t9 data URL: file:/tmp/.v9t9j/exec/ |
|
2015-07-05 14:18:49,042 DEBUG main - URI created from file:/tmp/.v9t9j/exec/v9t9-data.jar!/ti99/images/ as file:/tmp/.v9t9j/exec/v9t9-data.jar!/ti99/images/ |
|
2015-07-05 14:18:50,311 DEBUG CPU Runner - URI created from file:/tmp/.v9t9j/exec/v9t9-data.jar!/ti99/images/ as file:/tmp/.v9t9j/exec/v9t9-data.jar!/ti99/images/ |
|
OK. Thanks. I forgot I asked for the debug log -- I guess that's not necessary now that you've got sound of some kind. (I mainly wanted to verify that "Using JRE for sound" was present.) :) There's no logging yet that will explain, though, why the sound is choppy. Sigh. But your CPU seems to be a little slower than mine. I noticed you clipped off the /proc/cpuinfo report -- I'm assuming there's more than one there. How many cores do you have? BTW, I'm looking into making the video synchronization smarter as we speak. I'll move that into a separate bug, though, since this one is getting a bit overloaded. :) |
|
OK, and please note that everything I wrote is meant as feedback, not criticism. In fact, I like that v9t9 uses so little CPU, even if it means compromising on the fidelity of analogous outputs. |
|
I was finally able to reproduce the kind of performance issues you see by using the "zero" JVM for OpenJDK, which does no runtime optimization at all (all interpreted!). Your java -version clearly shows it's not using this, but I guess this matches my system to the performance of Java in your system. Oof. I will try to optimize stuff in zero mode. |
|
Fixed in 2015/07/21 release. |
and others
Hello,
Starting v9t9 on Ubuntu 14.04 fails with this error message:
There is an incompatible JNA native library installed on this system.
To resolve this issue you may do one of the following:
remove or uninstall the offending library
set the system property jna.nosys=true
set jna.boot.library.path to include the path to the version of the
jnidispatch library included with the JNA jar file you are using
When I add -Djna.nosys=true to v9t9.sh, then I get this error message:
ALSA lib pcm.c:7986:(snd_pcm_set_params) Unable to get period size for PLAYBACK: Invalid argument
Java version:
tiger /opt/v9t9 > java -version
java version "1.7.0_79"
OpenJDK Runtime Environment (IcedTea 2.5.5) (7u79-2.5.5-0ubuntu0.14.04.2)
OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode)
The text was updated successfully, but these errors were encountered: