Bug 501048 - No sound from tuxguitar
Summary: No sound from tuxguitar
Keywords:
Status: CLOSED DUPLICATE of bug 505421
Alias: None
Product: Fedora
Classification: Fedora
Component: tuxguitar
Version: 11
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Orcan Ogetbil
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-05-15 17:01 UTC by Brian G. Anderson
Modified: 2021-10-19 10:43 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-06-11 05:24:53 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Java sound properties (1.82 KB, application/octet-stream)
2009-09-02 17:50 UTC, Brian G. Anderson
no flags Details
Load Fedora defaults (1.69 KB, patch)
2009-11-25 07:01 UTC, Orcan Ogetbil
no flags Details | Diff
multilib patch (3.43 KB, patch)
2009-11-26 07:02 UTC, Orcan Ogetbil
no flags Details | Diff
build-fedora.xml (11.57 KB, application/xml)
2009-11-27 07:06 UTC, Orcan Ogetbil
no flags Details

Description Brian G. Anderson 2009-05-15 17:01:40 UTC
Description of problem:
Tuxguitar has a number of problems in F11 rawhide:
1) it puts out a stack trace on the console
2) it puts up a warning about "An error occured when trying to set plugin status" and then about "Java sound api cannot be installed"
3) it attempts to play but no sound

I also tried to start timidity++ as "timidity -iAD" which is what I do in fc10.  Timidity has problems starting, but even when I get around these problems no sound when playing;  the midi ports appear in the sound configuration screen, however).


Version-Release number of selected component (if applicable):
tuxguitar-1.1-1.fc11.x86_64

How reproducible:


Steps to Reproduce:
1. Install tuxguitar
2. run it and try and play the initial sample
3. start timidity++ and set tuxguiter to use a midi port and try and play a sample.
  
Actual results:
Appears to play but now sound.

Expected results:
Sound.

Additional info:
The following is the console output

$MOZILLA_FIVE_HOME not valid : check doc shipped w/ tuxguitar
/dev/sequencer: No such file or directory
org.herac.tuxguitar.gui.system.plugins.TGPluginException: Java sound api cannot be loaded
   at org.herac.tuxguitar.gui.system.plugins.base.TGMidiOutputPortProviderPlugin.addPlugin(tuxguitar.jar.so)
   at org.herac.tuxguitar.gui.system.plugins.base.TGMidiOutputPortProviderPlugin.setEnabled(tuxguitar.jar.so)
   at org.herac.tuxguitar.gui.system.plugins.base.TGPluginList.setEnabled(tuxguitar.jar.so)
   at org.herac.tuxguitar.gui.system.plugins.TGPluginManager.openPlugins(tuxguitar.jar.so)
   at org.herac.tuxguitar.gui.TuxGuitar.displayGUI(tuxguitar.jar.so)
   at org.herac.tuxguitar.gui.TGMain.main(tuxguitar.jar.so)
Caused by: org.herac.tuxguitar.player.base.MidiPlayerException: Java sound api cannot be loaded
   at org.herac.tuxguitar.player.impl.jsa.midiport.MidiPortProviderImpl.listPorts(tuxguitar-jsa.jar.so)
   at org.herac.tuxguitar.player.base.MidiPlayer.addOutputPortProvider(tuxguitar.jar.so)
   at org.herac.tuxguitar.gui.system.plugins.base.TGMidiOutputPortProviderPlugin.addPlugin(tuxguitar.jar.so)
   ...5 more
Caused by: java.lang.UnsatisfiedLinkError: init_
   at gnu.javax.sound.midi.alsa.AlsaMidiDeviceProvider.init_(libgcj.so.10)
   at gnu.javax.sound.midi.alsa.AlsaMidiDeviceProvider.<clinit>(libgcj.so.10)
   at java.lang.Class.initializeClass(libgcj.so.10)
   at java.lang.Class.newInstance(libgcj.so.10)
   at gnu.classpath.ServiceProviderLoadingAction.run(libgcj.so.10)
   at java.security.AccessController.doPrivileged(libgcj.so.10)
   at gnu.classpath.ServiceFactory$ServiceIterator.loadNextServiceProvider(libgcj.so.10)
   at gnu.classpath.ServiceFactory$ServiceIterator.<init>(libgcj.so.10)
   at gnu.classpath.ServiceFactory.lookupProviders(libgcj.so.10)
   at gnu.classpath.ServiceFactory.lookupProviders(libgcj.so.10)
   at gnu.classpath.ServiceFactory.lookupProviders(libgcj.so.10)
   at javax.sound.midi.MidiSystem.getMidiDeviceInfo(libgcj.so.10)
   at org.herac.tuxguitar.player.impl.jsa.midiport.MidiPortProviderImpl.listPorts(tuxguitar-jsa.jar.so)
   ...7 more
ALSA lib seq_hw.c:457:(snd_seq_hw_open) open /dev/snd/seq failed: No such file or directory
org.herac.tuxguitar.gui.system.plugins.TGPluginException: An error ocurred when trying to set plugin status
   at org.herac.tuxguitar.gui.system.plugins.TGPluginManager.openPlugins(tuxguitar.jar.so)
   at org.herac.tuxguitar.gui.TuxGuitar.displayGUI(tuxguitar.jar.so)
   at org.herac.tuxguitar.gui.TGMain.main(tuxguitar.jar.so)
Caused by: java.lang.NoClassDefFoundError: org.herac.tuxguitar.io.gervill.MidiToAudioSynth
   at java.lang.Class.initializeClass(libgcj.so.10)
   at org.herac.tuxguitar.io.gervill.MidiToAudioPlugin.setEnabled(tuxguitar-gervill.jar.so)
   at org.herac.tuxguitar.gui.system.plugins.TGPluginManager.openPlugins(tuxguitar.jar.so)
   ...2 more
Caused by: java.lang.ClassNotFoundException: com.sun.media.sound.SoftSynthesizer not found in org.herac.tuxguitar.util.TGClassLoader$URLClassLoaderImpl{urls=[file:/usr/share/tuxguitar/plugins/tuxguitar-compat.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-converter.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-oss.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-jsa.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-midi.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-pdf.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-browser-ftp.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-ptb.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-alsa.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-gervill.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-gtp.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-fluidsynth.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-ascii.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-tef.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-lilypond.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-musicxml.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-tray.jar], parent=gnu.gcj.runtime.SystemClassLoader{urls=[file:/usr/lib64/java/swt.jar,file:/usr/share/tuxguitar/,file:/usr/share/tuxguitar//tuxguitar.jar,file:/usr/share/java/itext.jar,file:/usr/lib64/java/swt.jar,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}}
   at java.net.URLClassLoader.findClass(libgcj.so.10)
   at java.lang.ClassLoader.loadClass(libgcj.so.10)
   at java.lang.ClassLoader.loadClass(libgcj.so.10)
   at java.lang.Class.initializeClass(libgcj.so.10)
   ...4 more
org.herac.tuxguitar.player.base.MidiPlayerException: Java sound api cannot be loaded
   at org.herac.tuxguitar.player.impl.jsa.midiport.MidiPortProviderImpl.listPorts(tuxguitar-jsa.jar.so)
   at org.herac.tuxguitar.player.base.MidiPlayer.listOutputPorts(tuxguitar.jar.so)
   at org.herac.tuxguitar.player.base.MidiPlayer.openOutputPort(tuxguitar.jar.so)
   at org.herac.tuxguitar.gui.TuxGuitar.restorePlayerConfig(tuxguitar.jar.so)
   at org.herac.tuxguitar.gui.TuxGuitar.displayGUI(tuxguitar.jar.so)
   at org.herac.tuxguitar.gui.TGMain.main(tuxguitar.jar.so)
Caused by: java.lang.NoClassDefFoundError: gnu.javax.sound.midi.alsa.AlsaMidiDeviceProvider
   at java.lang.Class.initializeClass(libgcj.so.10)
   at java.lang.Class.newInstance(libgcj.so.10)
   at gnu.classpath.ServiceProviderLoadingAction.run(libgcj.so.10)
   at java.security.AccessController.doPrivileged(libgcj.so.10)
   at gnu.classpath.ServiceFactory$ServiceIterator.loadNextServiceProvider(libgcj.so.10)
   at gnu.classpath.ServiceFactory$ServiceIterator.<init>(libgcj.so.10)
   at gnu.classpath.ServiceFactory.lookupProviders(libgcj.so.10)
   at gnu.classpath.ServiceFactory.lookupProviders(libgcj.so.10)
   at gnu.classpath.ServiceFactory.lookupProviders(libgcj.so.10)
   at javax.sound.midi.MidiSystem.getMidiDeviceInfo(libgcj.so.10)
   at org.herac.tuxguitar.player.impl.jsa.midiport.MidiPortProviderImpl.listPorts(tuxguitar-jsa.jar.so)
   ...5 more

Comment 1 Orcan Ogetbil 2009-05-15 17:27:25 UTC
Thanks for the report.

First of all, which java are you using? Look at what
   alternatives --config java
says. Sound output will not work if you use gcj. You need either openjdk or Sun's java for sound output. If you need to change the java you are using, you need to execute the above command as root.

Secondly,
After starting timidity, in Tools->Settings->Sound->Midi Port, you need to select one of the "Timidity Port"s to use timidity.

Alternatively, you can select "Gervill" to use Java Sound API, or select "Synth Input port" tu use fluidsynth. 

I recommend using fluidsynth. At least that works best on my system. But for fluidsynth, you will need to start the daemon on the background, as you did for timidity. A very nice GUI tool called "qsynth" can be used for this purpose. After qsynth starts the fluidsynth daemon, you will be able to select "Synth Input port" in Tools->Settings->Sound->Midi Port.

Do some experiments with these midi ports and please let me know of the outcome.

Comment 2 Brian G. Anderson 2009-05-15 17:44:04 UTC
Sorry I forgot that important information.  I'm using "/usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java" as reported by the alternatives command.

The sound problem is due to a timidity bug and I've reported that.

However, all the scary error messages still appear and they seem unrelated to the timidity problem.  I can get rid of the Java API one by going to the plugin screen and unselecting it, but it doesn't get rid of the "problem setting up plugin".

Comment 3 Orcan Ogetbil 2009-05-15 17:52:52 UTC
Hmm, it works on my system (F-10) without error messages. Maybe there's a problem with F-11's openjdk. I can't confirm it for the time being as I don't have a running F-11 box.

I'll let you know if I can locate the problem.

Comment 4 Orcan Ogetbil 2009-05-15 17:55:03 UTC
Is there a way you can test this with Sun's java on F-11? If you can, that will tell us whether the problem is in tuxguitar or in openjdk.

Comment 5 Brian G. Anderson 2009-05-15 19:29:37 UTC
I get errors, but different ones now.  It's complaining about the Gervill synthesizer not being available.

$MOZILLA_FIVE_HOME not valid : check doc shipped w/ tuxguitar
/dev/sequencer: No such file or directory
java.lang.ClassNotFoundException: com.sun.media.sound.SoftSynthesizer
	at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:247)
	at org.herac.tuxguitar.io.gervill.MidiToAudioSynth.isAvailable(MidiToAudioSynth.java:61)
	at org.herac.tuxguitar.io.gervill.MidiToAudioPlugin.setEnabled(MidiToAudioPlugin.java:14)
	at org.herac.tuxguitar.gui.system.plugins.TGPluginManager.openPlugins(TGPluginManager.java:62)
	at org.herac.tuxguitar.gui.TuxGuitar.displayGUI(TuxGuitar.java:212)
	at org.herac.tuxguitar.gui.TGMain.main(TGMain.java:6)
org.herac.tuxguitar.gui.system.plugins.TGPluginException: Gervill Synthesizer is not available
	at org.herac.tuxguitar.io.gervill.MidiToAudioPlugin.setEnabled(MidiToAudioPlugin.java:15)
	at org.herac.tuxguitar.gui.system.plugins.TGPluginManager.openPlugins(TGPluginManager.java:62)
	at org.herac.tuxguitar.gui.TuxGuitar.displayGUI(TuxGuitar.java:212)
	at org.herac.tuxguitar.gui.TGMain.main(TGMain.java:6)

Comment 6 Orcan Ogetbil 2009-05-15 20:44:08 UTC
It's basically the same problem. 
   java.lang.ClassNotFoundException: com.sun.media.sound.SoftSynthesizer
both with openjdk and Sun's java. However this is an internal class and it should come with openjdk. It also comes with Sun's java (of course, with different implementation).

I suspect that there is something wrong with the way java is installed on your system. I even installed tuxguitar-1.1-1.fc11 on my F-10 system and it just works.

Did you try other java applications that make use of java sound API?

Comment 7 Brian G. Anderson 2009-05-15 21:35:38 UTC
I'm running FC11 preview and the openjdk comes from there.  As for the sun JDK I downloaded the sun RPM and installed it.  Otherwise this is a stock system.  Since the same error occurs in two different JVM installed in two different locations (openJDK is hooked up to the /etc/alternatives system while SUN installs in /usr/java/latest) I'm at a loss to determine what common bit could cause the same failure.  Am I missing a library?  If I am, why didn't the standard setup for OpenJDK install it?

I don't know of any other FC11 program that uses the sound API, but I'd be willing to test one if you could point me to it.

Comment 8 Orcan Ogetbil 2009-05-17 02:01:41 UTC
Honestly, I don't know of any other java application we have in Fedora that makes use of java sound API, except frinika (bug #492203) but that is not accepted to Fedora yet, and to build it one will need to build a chain of dependencies first.

I informed folks at fedora-java about this. Also I will have an F-11 machine (hopefully) this week. I can then have a look at the issue myself.

Comment 9 Orcan Ogetbil 2009-06-01 23:05:22 UTC
I installed F-11 today and I am unable to reproduce what you are experiencing. My 
   /dev/sequencer
is present out of the box and tuxguitar works just as it is supposed to. I suspect a misconfiguration in your audio setup.

Comment 10 Orcan Ogetbil 2009-06-08 03:39:27 UTC
Brian, I really can't reproduce your issue. Did you find a solution?

Comment 11 Brian G. Anderson 2009-06-08 04:25:25 UTC
So the sound issue is really a timidity issue.  I can get sound from tuxguitar when I do the proper kung-fu with Timidity.

However all the other scary error messages come up. Are you saying that you don't see any error messages from Tuxguitar when it starts up?

I've installed x86_64 FC11.  Could it be a 64bit setup problem?

Comment 12 Orcan Ogetbil 2009-06-08 04:40:32 UTC
Nope. The only message I get on my x86_64 is
   $MOZILLA_FIVE_HOME not valid : check doc shipped w/ tuxguitar
which shouldn't be fatal. By the way, there was a recent timidity update:
   http://cvs.fedora.redhat.com/viewvc/devel/timidity%2B%2B/timidity%2B%2B.spec?view=log

I don't know but it might be related to your case (I wasn't suffering from it myself).

What is your experience when you select gervill, or Synth Input Port (after you start qsynth)?

Comment 13 Orcan Ogetbil 2009-06-08 05:17:13 UTC
(In reply to comment #12)
> 
> What is your experience when you select gervill, or Synth Input Port (after you
> start qsynth)?  

The reason I'm asking you this is that I want to make sure that the problem is with timidity only. It might not be related to tuxguitar at all.

(I just saw that you reported bug 501051 and the timidity update that I mentioned came after that bug report.)

Comment 14 Jon Escombe 2009-06-08 07:49:23 UTC
Fwiw, I had a similar problem (same error messages) with my Fedora 11 / Sun java installation. 

There were a couple of issues with the java audio -

Needs to run under padsp in order to redirect the java (OSS) sound through pulseaudio (not new to F11).

It was trying to load the Gervill Plugin by default when I was using Sun java, so just needed to untick the plugin to silence the error.

It's worth noting that I'd previously enabled OSS in order to get the ALSA sequencer device back..

It's also worth noting that it all worked fine with an external softsynth (fluidsynth in my case), I just wanted to get to the bottom of the java sound issues.

Comment 15 Bug Zapper 2009-06-09 15:54:17 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 16 Brian G. Anderson 2009-06-11 01:03:49 UTC
I've done a fresh install of the release FC11.  I only have the open-jdk that was installed with the system.  I installed the 32 bit version just to eliminate any question of it being a 64bit problem.  I installed tuxguitar.

I get all the error messages about the Java api not being found just like before (see below).  I wiped the disk before hand to make sure there was no residual configs.

I downloaded the timidity fix and it does fix that problem, but all the issues with tuxguitar remain.  The only way to get rid of all the messages is to disable the Java API plugin and the Grevill pluin

#14 mentioned running under padsp.  This doesn't clear any errors up for me, and even if it did I thought openjdk doesn't use OSS anyway

#13 I never get an option to select Grevill output.  In fact, until I start timidity I have no selectable outputs.  If I start jackd and then qsyth I can get the fluidsynth output and that works fine.

So to sum up.  Out of the box, tuxguitar spews errors about not supporting the Java sound API or Gervill.  This is a fresh install as of today.


$MOZILLA_FIVE_HOME not valid : check doc shipped w/ tuxguitar
/dev/sequencer: No such file or directory
org.herac.tuxguitar.gui.system.plugins.TGPluginException: Java sound api cannot be loaded
   at org.herac.tuxguitar.gui.system.plugins.base.TGMidiOutputPortProviderPlugin.addPlugin(tuxguitar.jar.so)
   at org.herac.tuxguitar.gui.system.plugins.base.TGMidiOutputPortProviderPlugin.setEnabled(tuxguitar.jar.so)
   at org.herac.tuxguitar.gui.system.plugins.base.TGPluginList.setEnabled(tuxguitar.jar.so)
   at org.herac.tuxguitar.gui.system.plugins.TGPluginManager.openPlugins(tuxguitar.jar.so)
   at org.herac.tuxguitar.gui.TuxGuitar.displayGUI(tuxguitar.jar.so)
   at org.herac.tuxguitar.gui.TGMain.main(tuxguitar.jar.so)
Caused by: org.herac.tuxguitar.player.base.MidiPlayerException: Java sound api cannot be loaded
   at org.herac.tuxguitar.player.impl.jsa.midiport.MidiPortProviderImpl.listPorts(tuxguitar-jsa.jar.so)
   at org.herac.tuxguitar.player.base.MidiPlayer.addOutputPortProvider(tuxguitar.jar.so)
   at org.herac.tuxguitar.gui.system.plugins.base.TGMidiOutputPortProviderPlugin.addPlugin(tuxguitar.jar.so)
   ...5 more
Caused by: java.lang.UnsatisfiedLinkError: init_
   at gnu.javax.sound.midi.alsa.AlsaMidiDeviceProvider.init_(libgcj.so.10)
   at gnu.javax.sound.midi.alsa.AlsaMidiDeviceProvider.<clinit>(libgcj.so.10)
   at java.lang.Class.initializeClass(libgcj.so.10)
   at java.lang.Class.newInstance(libgcj.so.10)
   at gnu.classpath.ServiceProviderLoadingAction.run(libgcj.so.10)
   at java.security.AccessController.doPrivileged(libgcj.so.10)
   at gnu.classpath.ServiceFactory$ServiceIterator.loadNextServiceProvider(libgcj.so.10)
   at gnu.classpath.ServiceFactory$ServiceIterator.<init>(libgcj.so.10)
   at gnu.classpath.ServiceFactory.lookupProviders(libgcj.so.10)
   at gnu.classpath.ServiceFactory.lookupProviders(libgcj.so.10)
   at gnu.classpath.ServiceFactory.lookupProviders(libgcj.so.10)
   at javax.sound.midi.MidiSystem.getMidiDeviceInfo(libgcj.so.10)
   at org.herac.tuxguitar.player.impl.jsa.midiport.MidiPortProviderImpl.listPorts(tuxguitar-jsa.jar.so)
   ...7 more
org.herac.tuxguitar.gui.system.plugins.TGPluginException: An error ocurred when trying to set plugin status
   at org.herac.tuxguitar.gui.system.plugins.TGPluginManager.openPlugins(tuxguitar.jar.so)
   at org.herac.tuxguitar.gui.TuxGuitar.displayGUI(tuxguitar.jar.so)
   at org.herac.tuxguitar.gui.TGMain.main(tuxguitar.jar.so)
Caused by: java.lang.NoClassDefFoundError: org.herac.tuxguitar.io.gervill.MidiToAudioSynth
   at java.lang.Class.initializeClass(libgcj.so.10)
   at org.herac.tuxguitar.io.gervill.MidiToAudioPlugin.setEnabled(tuxguitar-gervill.jar.so)
   at org.herac.tuxguitar.gui.system.plugins.TGPluginManager.openPlugins(tuxguitar.jar.so)
   ...2 more
Caused by: java.lang.ClassNotFoundException: com.sun.media.sound.SoftSynthesizer not found in org.herac.tuxguitar.util.TGClassLoader$URLClassLoaderImpl{urls=[file:/usr/share/tuxguitar/plugins/tuxguitar-gtp.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-compat.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-pdf.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-tray.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-browser-ftp.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-ascii.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-alsa.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-oss.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-midi.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-tef.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-musicxml.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-jsa.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-fluidsynth.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-gervill.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-converter.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-ptb.jar,file:/usr/share/tuxguitar/plugins/tuxguitar-lilypond.jar], parent=gnu.gcj.runtime.SystemClassLoader{urls=[file:/usr/lib/java/swt.jar,file:/usr/share/tuxguitar/,file:/usr/share/tuxguitar//tuxguitar.jar,file:/usr/share/java/itext.jar,file:/usr/lib/java/swt.jar,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}}
   at java.net.URLClassLoader.findClass(libgcj.so.10)
   at java.lang.ClassLoader.loadClass(libgcj.so.10)
   at java.lang.ClassLoader.loadClass(libgcj.so.10)
   at java.lang.Class.initializeClass(libgcj.so.10)
   ...4 more
org.herac.tuxguitar.player.base.MidiPlayerException: Java sound api cannot be loaded
   at org.herac.tuxguitar.player.impl.jsa.midiport.MidiPortProviderImpl.listPorts(tuxguitar-jsa.jar.so)
   at org.herac.tuxguitar.player.base.MidiPlayer.listOutputPorts(tuxguitar.jar.so)
   at org.herac.tuxguitar.player.base.MidiPlayer.openOutputPort(tuxguitar.jar.so)
   at org.herac.tuxguitar.gui.TuxGuitar.restorePlayerConfig(tuxguitar.jar.so)
   at org.herac.tuxguitar.gui.TuxGuitar.displayGUI(tuxguitar.jar.so)
   at org.herac.tuxguitar.gui.TGMain.main(tuxguitar.jar.so)
Caused by: java.lang.NoClassDefFoundError: gnu.javax.sound.midi.alsa.AlsaMidiDeviceProvider
   at java.lang.Class.initializeClass(libgcj.so.10)
   at java.lang.Class.newInstance(libgcj.so.10)
   at gnu.classpath.ServiceProviderLoadingAction.run(libgcj.so.10)
   at java.security.AccessController.doPrivileged(libgcj.so.10)
   at gnu.classpath.ServiceFactory$ServiceIterator.loadNextServiceProvider(libgcj.so.10)
   at gnu.classpath.ServiceFactory$ServiceIterator.<init>(libgcj.so.10)
   at gnu.classpath.ServiceFactory.lookupProviders(libgcj.so.10)
   at gnu.classpath.ServiceFactory.lookupProviders(libgcj.so.10)
   at gnu.classpath.ServiceFactory.lookupProviders(libgcj.so.10)
   at javax.sound.midi.MidiSystem.getMidiDeviceInfo(libgcj.so.10)
   at org.herac.tuxguitar.player.impl.jsa.midiport.MidiPortProviderImpl.listPorts(tuxguitar-jsa.jar.so)
   ...5 more

Comment 17 Orcan Ogetbil 2009-06-11 03:52:56 UTC
Thanks for the extensive report. However, I'm unable to reproduce this on any of my computers.

I do suspect that the problem is given at the beginning of your tuxguitar output:
   /dev/sequencer: No such file or directory
My guess is that the java sound api fails to initialize when /dev/sequencer is missing.

Did you have this issue (not having /dev/sequencer) before? F-10 or before? or another distro?

You can try to create this yourself. As root, try this
   modprobe snd-seq-oss
   modprobe snd-seq
One of these should create /dev/sequencer

Why is this not done by udev? I don't know that. It may be a bug in udev or kernel (the alsa drivers).

Comment 18 Orcan Ogetbil 2009-06-11 03:56:52 UTC
... or maybe your sound hardware does not support MIDI.

Comment 19 Brian G. Anderson 2009-06-11 04:49:55 UTC
Ok,  I have to do the two modprobes to get tuxguitar to quit complaining and for the Gervill option to appear.  So perhaps the bug is why in a clean system snd-seq-oss and snd-seq are not loaded by default?

Comment 20 Orcan Ogetbil 2009-06-11 05:24:53 UTC
(In reply to comment #19)
> Ok,  I have to do the two modprobes to get tuxguitar to quit complaining and
> for the Gervill option to appear.  So perhaps the bug is why in a clean system
> snd-seq-oss and snd-seq are not loaded by default?  

Yes, that's the main question now. I don't know exactly what is responsible for loading the snd-seq-oss and snd-seq modules (udev? kernel? hal?). 

Could you file this bug against kernel? It would be good to tell them your hardware info and possible error messages in system log. They respond fast, usually. Also please add me to the CC list.

I'm closing this bug now. I don't think there's something wrong with tuxguitar.

Comment 21 Jon Escombe 2009-06-11 08:14:18 UTC
I needed to uncomment a line in /etc/modprobe.d/dist-oss.conf to load those modules.. Appears they're caught up in the "disable OSS" feature of F11.

Comment 22 Orcan Ogetbil 2009-06-12 00:24:24 UTC
It looks like a bug is opened already.

*** This bug has been marked as a duplicate of bug 505421 ***

Comment 23 Brian G. Anderson 2009-06-15 13:06:41 UTC
Well now I'm confused.  I reinstalled FC11 64 and even when I do the modprobes I still get the errors about classes not found.  Only disabling the Java API and Gervill plugins make tuxguitar not complain.

Comment 24 Ben Engbers 2009-08-02 15:18:38 UTC
(In reply to comment #9)
> I installed F-11 today and I am unable to reproduce what you are experiencing.
> My 
>    /dev/sequencer
> is present out of the box and tuxguitar works just as it is supposed to. I
> suspect a misconfiguration in your audio setup. 

About a year ago, I did a clean install of FC 10 on my Toshiba harman/kardon laptop. Everything worked fine and sound-devices were recognized out of the box.
As far as I can remember I had to export JAVA_HOME to get tuxguitar running.

With each automatic update of FC10, I had problems with audiopulse. Sometimes it worked and sometimes it didn't :-(
I finally got a stable system with a slightly corrupted sound-system. The sound procuced by the front-speakers was faintly audible but the earplugs worked well.

I now did an automatic upgrade to FC11.
Nothing has changed with the sound but
- tuxguitar worked only after changing the path to JAVA_HOME (line 154 in /usr/bin/tuxguitar)
- tuxguitar only shows the tabs but still produces no sound

How can I get sound in tuxguitar?
Where can I find how to configure my sound-card and how can I save those setings (in such a way that they aren't changed by every update of Fedora)?

Ben

Comment 25 Orcan Ogetbil 2009-08-02 17:48:48 UTC
Ben,
There is a problem with module-init-tools that prevents the loading of the snd-seq kernel module automatically. We are waiting for a fix on their side.

You can have a look at comment #17 above for manually loading the necessary module.

Comment 26 Ben Engbers 2009-09-02 12:13:09 UTC
(In reply to comment #25)
> Ben,
> There is a problem with module-init-tools that prevents the loading of the
> snd-seq kernel module automatically. We are waiting for a fix on their side.
> 
> You can have a look at comment #17 above for manually loading the necessary
> module. 
Hi,

The snd-seq modules are loaded so I know that sound should be working.

The problems with  MOZILLA_FIVE_HOME were solved after changing t="/usr/lib/xulrunner-1.9" to t="/usr/lib/xulrunner-1.9.1" but Tuxguitar still complains about the missing com.sun.media.sound.SoftSynthesizer.

After some searching, I found the file sound.properties in /usr/lib/jvm/jre-1.6.0-openjdk/lib and I noticed that it has no entries for midi-settings.

Is it possible that the problems with the sound are caused by this (and it is possible for you to show your sound.properties)?

Ben

Comment 27 Brian G. Anderson 2009-09-02 17:48:59 UTC
I don't know enough about Java sound API to say whether the contents of this file are causing my problems, but I've attached the file as it exists on my machine

Comment 28 Brian G. Anderson 2009-09-02 17:50:23 UTC
Created attachment 359562 [details]
Java sound properties

Comment 29 Ben Engbers 2009-09-02 19:48:29 UTC
(In reply to comment #28)
> Created an attachment (id=359562) [details]
> Java sound properties  

It's the same as my file :-(

What confuses me now is that after removing and installing TuxGuitar again, I accidentally clicked on the 'play' button. Although TuxGuitar still complains that the Gervill syntesizer is missing, it produces normal sound!?

Strange...

Comment 30 Julian Casadesus 2009-11-25 00:14:25 UTC
Hi, i'm tuxguitar's author. I see some issues here,

*
The first thing, is that the application is running under GCJ, but as default it's java sound api support don't works.
This is why you see the "Java sound api cannot be loaded" Error.
( if you want to run tuxguitar with GCJ, you have to disable/remove tuxguitar-jsa plugin to don't see that error )

>> Sorry I forgot that important information.
>> I'm using "/usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java" as reported by the alternatives command.

Well, if you see the error logs, you could make a search of the word "gcj"
You'll find a lot of lines ending with "(libgcj.so.10)"
Or you can run "tuxguitar -i", and it will display the JVM info.

*
Another problem, is that the launcher script is loading all plugins statically.
but some of them don't works in all JVMs, or need extra dependencies.

This is the cause of:
Caused by: java.lang.NoClassDefFoundError: org.herac.tuxguitar.io.gervill.MidiToAudioSynth

This class is loaded from tuxguitar-gervill plugin, that needs gervill library at classpath.
OpenJDK includes it as default.. but if you run tuxguitar with Sun's JDK, you have to add "gervill.jar" to the java classpath to make this plugin works.

*
/dev/sequencer: No such file or directory
This error is throwed by tuxguitar-oss plugin.

It's not recommended to have tuxguitar-oss with alsa or jsa enabled at same time.
in some systems ( i never knew the reason, i think it's something related to soundcard/driver )
OSS don't allows users to play 2 sound apps at same time.
when you have tuxguitar-oss plugin loaded, it can cause same effect with other sound plugins.
So my suggest is to disable it if your sound system isn't OSS.

( something similar happens with java sound api, and the java sound synthesizer provided by sun's JDK,  you have to run the application with alsa-oss, or padsp if you have pulseaudio installed )

So my suggestion is..
try to make the application run with openjdk, look for Gervill at MIDI Port and check if it works. if yes, then disable tuxguitar-oss, tuxguitar-alsa, tuxguitar-fluidsynth. then try to configure a nice soundfont to gervill for better quality.

Comment 31 Orcan Ogetbil 2009-11-25 03:04:56 UTC
(In reply to comment #30)
> Hi, i'm tuxguitar's author. I see some issues here,
> 

Hi Julian, thanks for stopping by. I am the package maintainer. If you remember, we had a discussion last year around this time in your forum.

> *
> The first thing, is that the application is running under GCJ, but as default
> it's java sound api support don't works.
> This is why you see the "Java sound api cannot be loaded" Error.
> ( if you want to run tuxguitar with GCJ, you have to disable/remove
> tuxguitar-jsa plugin to don't see that error )
> 
> >> Sorry I forgot that important information.
> >> I'm using "/usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java" as reported by the alternatives command.
> 
> Well, if you see the error logs, you could make a search of the word "gcj"
> You'll find a lot of lines ending with "(libgcj.so.10)"
> Or you can run "tuxguitar -i", and it will display the JVM info.
> 

In Fedora, the user has to do a
   alternatives --config java
to switch back and forth between openjdk and gcj (and sun's java if it is installed properly). I believe that the user got confused by what alternatives said. The openjdk is the default in Fedora, and the user has to switch to gcj manually by running the above command if he wants to use it instead.

> *
> Another problem, is that the launcher script is loading all plugins statically.
> but some of them don't works in all JVMs, or need extra dependencies.
> 
> This is the cause of:
> Caused by: java.lang.NoClassDefFoundError:
> org.herac.tuxguitar.io.gervill.MidiToAudioSynth
> 
> This class is loaded from tuxguitar-gervill plugin, that needs gervill library
> at classpath.
> OpenJDK includes it as default.. but if you run tuxguitar with Sun's JDK, you
> have to add "gervill.jar" to the java classpath to make this plugin works.
> 

I will add gervill.jar to the classpath so things will work with Sun's java.

> *
> /dev/sequencer: No such file or directory
> This error is throwed by tuxguitar-oss plugin.
> 
> It's not recommended to have tuxguitar-oss with alsa or jsa enabled at same
> time.

> So my suggest is to disable it if your sound system isn't OSS.
> 

The default Makefile had oss plugin enabled, so maybe I should disable it.

By the way, is there a reason why the Makefile is removed from the 1.2 source tarball?


> check if it works. if yes, then disable tuxguitar-oss, tuxguitar-alsa,
> tuxguitar-fluidsynth. then try to configure a nice soundfont to gervill for
> better quality.  

One last question: We have a default soundfont in Fedora that all our MIDI applications are using by default. What source files should I patch so that tuxguitar loads that soundfont by default? (It is the FluidR3 soundfont, the only comprehensive soundfont that is completely free) What is your suggestion?

Since this is a distribution, we would like to have things working out of the box with minimum requirement of manual user configuration.

Comment 32 Orcan Ogetbil 2009-11-25 06:59:56 UTC
(In reply to comment #31)
> One last question: We have a default soundfont in Fedora that all our MIDI
> applications are using by default. What source files should I patch so that
> tuxguitar loads that soundfont by default? (It is the FluidR3 soundfont, the
> only comprehensive soundfont that is completely free) What is your suggestion?
> 
> Since this is a distribution, we would like to have things working out of the
> box with minimum requirement of manual user configuration.  

Actually, I sat down and wrote a patch for loading fluidsynth plugin with alsa with our default soundfont by default. With this patch when someone installs and runs tuxguitar on Fedora, the sound will work right away, with a nice soundfont and without any manual configuration.

I am attaching the patch. Julian, could you see if the patch is okay with you?

Since we are in a distribution, we have the convenience of tweaking stuff for our own defaults. :)

Comment 33 Orcan Ogetbil 2009-11-25 07:01:02 UTC
Created attachment 373674 [details]
Load Fedora defaults

Comment 34 Julian Casadesus 2009-11-25 12:47:55 UTC
(In reply to comment #31)

> In Fedora, the user has to do a
>    alternatives --config java
> to switch back and forth between openjdk and gcj (and sun's java if it is
> installed properly). I believe that the user got confused by what alternatives
> said. The openjdk is the default in Fedora, and the user has to switch to gcj
> manually by running the above command if he wants to use it instead.

Yes but i still see something strange here..
In all exeption logs of libgj.. i see also some lines ending with (tuxguitar.jar.so)
so why .so ? it make me think that the user don't have a normal bytecode (java) tuxguitar version.. it's like if he would compiled the jars to native with GCJ.

I'm not clear sure with this.. i tested it at home (but under debian), starting tg under GCJ, with this plugins, and i see same error. but i don't see (tuxguitar.jar.so) aclarations.

> The default Makefile had oss plugin enabled, so maybe I should disable it.
To debian's mantainer, i suggested him make different packages for these plugins. alsa/oss/fluidsynth/jsa ( and now jack )

but debian users often install packages using apt-get.
not sure if fedora users often uses yum.. or if they download packages manually

on oficial release, as there is no yum, or apt..
what i did in last x86 release was to build all these plugins, but only jsa and alsa installed/enabled as default.
each plugin needs a META-INF/services/plugin_interface... with the plugin implementation class name.
just commenting this implementation class name.. the plugin is there but tuxguitar don't loads it.. 

if you download our package "GNU/Linux-x86 Binary Files", extract it and go to plugins folder you'll understand better what i try to say.

> By the way, is there a reason why the Makefile is removed from the 1.2 source
> tarball?

well how to say.. this make file is used for debian package mantainer. and it's at SVN.. i think by accindent i included it in older releases.
the story is that it have debian paths. and some users of other distributions are confused with it..

To build the application we uses ant scripts. where each project have it's own build.xml and build.properties. then user is able to build tuxguitar, and build only the plugins he want.
this makefile tries to call all ant scripts in one step, but as it's for debian, some paths (see swt, itext, jdk ) are hardcoded. and you cannot define plugins to build.

If you need it, it's available at SVN ( i'm not sure if it was updated to 1.2 at all )

Otherwise you could follow these steps:
http://www.tuxguitar.com.ar/tgwiki/doku.php?id=doc:build

and make your own make file to call these ants as you need in only one make.

> One last question: We have a default soundfont in Fedora that all our MIDI
> applications are using by default. What source files should I patch so that
> tuxguitar loads that soundfont by default? (It is the FluidR3 soundfont, the
> only comprehensive soundfont that is completely free) What is your suggestion?
>
It depends what MIDI Port you select.
timidty, fluidsynth (by plugin, or by alsa) and gervill have soundfont support.
but each one have a different way to configure..

if you go to JAVA_HOME/jre/lib/audio ( create the folder if not exists )
and you put a .sf2 file there (or make a symbolic link ).
then, gervill will take that soundfont as default. 
it's easy, the cons are that it takes some time to load the soundfont.

for timidity, you have to edit the .cfg file, often at /etc/timidity/timidity.cfg 

for fluidsynth under alsa.. run:
fluidsynth -a [driver] /path_to_soundfont.sf2
then let's tuxguitar know the alsa client:port.
the problem is that not all times the PC boot the port is the same...

for tuxguitar-fluidsynth plugin..
lets answer your next post..
I saw the patch.. it loos like fine. but did you know that you can set plugin defaults without have to patch it ?

as for tg you have a  tuxguitar.dist..
you can add a .cfg for each plugin that uses config.

see this line:
this.config = new TGPluginConfigManager("tuxguitar-fluidsynth");

it is telling the config manager, that the plugin's config is named "tuxguitar-fluidsynth"
then the config manager will look for the file: tuxguitar-fluidsynth.cfg at classpath. if it find it, so it will take the values as default.
so you can just add a  tuxguitar-fluidsynth.cfg file inside tuxguitar-fluidsynth.jar. with this config:

soundfont.count=1
soundfont.path0=/usr/share/soundfonts/default.sf2
audio.driver=alsa

( or you can configure it in the application, and when all is ready then take the file from  ~/.tuxguitar-1.2/plugins/tuxguitar-fluidsynth.cfg )


Isn't pulseaudio installed as default audio system in fedora ??
if yes i suggest you use it as audio driver:

audio.driver=pulseaudio
audio.period-size=1024

( it's important the period-size beetween 1024 to 2048 for pulse driver, otherwise it will no sound as you expect )

Comment 35 Orcan Ogetbil 2009-11-26 00:27:52 UTC
(In reply to comment #34)
> (In reply to comment #31)
> 
> > The openjdk is the default in Fedora, and the user has to switch to gcj
> > manually by running the above command if he wants to use it instead.
> 
> Yes but i still see something strange here..
> In all exeption logs of libgj.. i see also some lines ending with
> (tuxguitar.jar.so)

Yes it is strange. The user claims he is using openjdk but that output only occurs with gcj. It's either a bug in alternatives or user is confused.


> just commenting this implementation class name.. the plugin is there but
> tuxguitar don't loads it.. 
> 

Okay, I will build, but disable oss.


> > By the way, is there a reason why the Makefile is removed from the 1.2 source
> > tarball?
> 
> well how to say.. this make file is used for debian package mantainer. and it's
> at SVN.. i think by accindent i included it in older releases.
> 
> If you need it, it's available at SVN ( i'm not sure if it was updated to 1.2
> at all )
> 
> Otherwise you could follow these steps:
> http://www.tuxguitar.com.ar/tgwiki/doku.php?id=doc:build
> 
> and make your own make file to call these ants as you need in only one make.
> 

The Makefile in SVN was not updated by the time I packaged 1.2. I was patching the Makefile heavily to fit it to Fedora's paths etc. This was one of my very first packages. I think I can write my own build script and just do everything with ant now.


> timidty, fluidsynth (by plugin, or by alsa) and gervill have soundfont support.
> but each one have a different way to configure..
> 
> if you go to JAVA_HOME/jre/lib/audio ( create the folder if not exists )
> and you put a .sf2 file there (or make a symbolic link ).
> then, gervill will take that soundfont as default. 
> it's easy, the cons are that it takes some time to load the soundfont.
> 

Yes, our timidity and fluidsynth (through qsynth) are configured properly. I didn't know about the symlink trick for openjdk. Thanks for that. I tried it and it works. :)

I filed a bug 541466 to openjdk package so that symlink can be added.


> I saw the patch.. it loos like fine. but did you know that you can set plugin
> defaults without have to patch it ?
> 

Very useful information and it is definitely easier than maintaining patches. I will do things this way! I have mixed feelings about pulseaudio. It doesn't work in many (most?) computers. I prefer using alsa.

Thanks again!

Comment 36 Orcan Ogetbil 2009-11-26 07:01:42 UTC
Okay, I got rid of the debian Makefile and I wrote my own build script using ant. I think it is better to do it this way. But now I have more questions:

* I added a comment: # in META-INF/services/plugin_interface before the class name for oss. But the plugin is now unavailable in the Tools-> Plugins window. I want it to be available but unchecked, so that the user can make it available (check the box) when he wants. How do I do this?

* Debian loads a file (misc/tuxguitar.tg) by default on startup if no parameters are passed to tuxguitar. I think this is nicer than having nothing when we start tuxguitar. Can we make this the default behavior (when the executable gets no argumants)?

* I made this tuxguitar-multilib.patch (attached) for those Linux distributions which are using multilib, i.e. /usr/lib64 etc for library directories. I didn't change the default but now one can build the package with -Ddist.lib.suffix=64 flag. Can you apply this patch on the trunk? Thanks!

* I noticed a bug in tuxguitar. 
   - Load a soundfont in fluidsynth plugin
   - Load a song
   - The song plays fine with the soundfont
   - Now go back to Tools->Plugins->Fluidsynth and change the soundfont.
   - The song still plays with the old soundfont.
Where should I report this?

Comment 37 Orcan Ogetbil 2009-11-26 07:02:32 UTC
Created attachment 373924 [details]
multilib patch

Comment 38 Julian Casadesus 2009-11-26 12:56:30 UTC
> I have mixed feelings about pulseaudio. It doesn't
> work in many (most?) computers. I prefer using alsa.

Me too, but isn't the story here to make defaults, to work with a default fedora installation ?
User allways can customize the OS, and he may have OSS instead of ALSA, or he could configure Jack to run in top of alsa, etc...

but if you want it works as default, you have to see what is the default fedora sound configuration after make a fresh install..
so, if i put a fedora CD, and make an install "next, next, next" ( without modify anything.. what is the default audio system installed ?

> the plugin is now unavailable in the Tools-> Plugins window.
> I want it to be available but unchecked

Well yes, without plugin info, it's like if it isn't installed.
unfortunatly there is no a "default" file for set plugin status yet. ( i'll add support for this.. )
The only way you have to do that, is by writing on the users's config file
so it means, the launcher script should check at ~/.tuxguitar-1.2 if file don't exist, just create it.
the file is named "plugin.properties". try disable any plugin.. and then see how is it created. 
However, this plugin isn't often used by gnu/linux users. ( it was more planned for freebsd, where there is no ALSA )

> Debian loads a file (misc/tuxguitar.tg)
Debian mantainer uses the tuxguitar.sh that is at "misc" folder.
there he make some check: [ -z "$1" ] && arg="/usr/share/tuxguitar/tuxguitar.tg"

On fedora (or any other distribution ) you also have static paths, so you can use this file or a new one modified..

Note that the dynamic launcher we create in build-linux.xml is planned to work with paths setted in build.properties, ( as default we use relative paths to don't force user to be root to install the aplication )

> I made this tuxguitar-multilib.patch
yes you are right, i see that the script isn't watching at lib64 folders..
could i maybe add os.library.path, and java.library.path to build.properties instead ? so if anybody have libraries at.. /opt/[aplication]/lib, he could use them without have to modify build.xml. what do you think ?

> I noticed a bug in tuxguitar. 

No really sure if is a bug. it could be but not as you think.
Note that this plugin creates one midi port by each soundfont.
so the bug is that "song didn't stop"
but the song don't have to play with the new soundfont, because you have to select the new MIDI port before.

In other words..
if you select 2 soundfonts "sf1 and sf2"
you have to see 2 midi ports then:
TG Fluidsynth[sf1]
TG Fluidsynth[sf2]

if you select "TG Fluidsynth[sf1]" 
and then remove it and add a new one "sf3"..
the application will not take "TG Fluidsynth[sf3]" as a selected port.

Comment 39 Julian Casadesus 2009-11-26 13:42:04 UTC
I made a little change to svn version to have a default plugin file.
so if you want to patch it to have this support, i suggest you use this file ( that will be included in next release ) as reference.

See here:
http://tuxguitar.svn.sourceforge.net/viewvc/tuxguitar/trunk/TuxGuitar/src/org/herac/tuxguitar/gui/system/plugins/TGPluginProperties.java?view=markup

I modified the "getDefaults()" method, it just takes "plugin.properties" from classpath if exists as default file.

I think in the future i'm going to rename these files..
to something more nice, like: tuxguitar.cfg and tuxguitar-plugins.cfg.. in both defaults and user files.

Comment 40 Orcan Ogetbil 2009-11-26 20:46:48 UTC
(In reply to comment #38)
> so, if i put a fedora CD, and make an install "next, next, next" ( without
> modify anything.. what is the default audio system installed ?
> 

I am not exactly sure. The Fedora Gnome edition probably has pulseaudio by default. The KDE edition uses Alsa as far as I know (but they were talking about changing it to puleaudio). My edition :) is to remove pulseaudio as soon as I install Fedora. Once it costed me a harddrive to keep pulseaudio enabled.

But if that's your primary recommendation, I can do it that way.

> > the plugin is now unavailable in the Tools-> Plugins window.
> > I want it to be available but unchecked
> 
> Well yes, without plugin info, it's like if it isn't installed.
> ...

Thanks for the update. I will backport that patch from trunk to our 1.2 release, so we can have oss plugin disabled (but can be enabled by user). I also want to do the same thing with the tray plugin.

> Note that the dynamic launcher we create in build-linux.xml is planned to work
> with paths setted in build.properties, ( as default we use relative paths to
> don't force user to be root to install the aplication )

Can you add a couple lines to build-linux.xml so we can specify a default file during the build? Something like

<echo file="${file.script}" append="true">arg=""${line.separator}</echo>
<echo file="${file.script}" append="true">if [ ! "$1" ] ; then arg="${dist.default.song}"; fi${line.separator}</echo>
<echo file="${file.script}" append="true">${JAVA} ${VM_ARGS} -cp :${CLASSPATH} -Dtuxguitar.share.path="${dist.share.path}" -Djava.library.path="${LD_LIBRARY_PATH}" ${MAINCLASS} "$1" "$2" "$arg"${line.separator}</echo>

> 
> > I made this tuxguitar-multilib.patch
> yes you are right, i see that the script isn't watching at lib64 folders..
> could i maybe add os.library.path, and java.library.path to build.properties
> instead ? so if anybody have libraries at.. /opt/[aplication]/lib, he could use
> them without have to modify build.xml. what do you think ?
> 

That's a good idea! Better than my patch.

> > I noticed a bug in tuxguitar. 
> 
> No really sure if is a bug. it could be but not as you think.
> Note that this plugin creates one midi port by each soundfont.
> so the bug is that "song didn't stop"
> but the song don't have to play with the new soundfont, because you have to
> select the new MIDI port before.
> 
> In other words..
> if you select 2 soundfonts "sf1 and sf2"
> you have to see 2 midi ports then:
> TG Fluidsynth[sf1]
> TG Fluidsynth[sf2]
> 
> if you select "TG Fluidsynth[sf1]" 
> and then remove it and add a new one "sf3"..
> the application will not take "TG Fluidsynth[sf3]" as a selected port.  

Exactly. But, right at this point, if you go to Tools->Settings->Sound, you will see that TG Fluidsynth[sf3] is selected as the Midi Port. But it is only effective when you restart the sound backend of tuxguitar.

Comment 41 Julian Casadesus 2009-11-26 21:37:57 UTC
(In reply to comment #40)

> But if that's your primary recommendation, I can do it that way.

Well no, my recommendation is use the driver of the sound system user is running :)..
if you could check that in a script, you could dynamically add default files at boot time.
see something like add a new "etc" classpath folder.
then you copy default files there ( ofcourse remove files inside tuxguitar.jar )

so if the script could check, it could do:
echo "[the best drive]" >  /etc/[the default config file]

In this case every user may be able to play sounds as default.


> <echo file="${file.script}" append="true">arg=""${line.separator}</echo>
> <echo file="${file.script}" append="true">if [ ! "$1" ] ; then
> arg="${dist.default.song}"; fi${line.separator}</echo>
> <echo file="${file.script}" append="true">${JAVA} ${VM_ARGS} -cp :${CLASSPATH}
> -Dtuxguitar.share.path="${dist.share.path}"
> -Djava.library.path="${LD_LIBRARY_PATH}" ${MAINCLASS} "$1" "$2"
> "$arg"${line.separator}</echo>
> 

hmm i'm not sure, cause this build.xml file is the one that we used to distribute official releases, but we don't distribute it with the example file..

However, the idea of build.xml is to be able to create custom build-[dist].xml

this build-linux.xml, is a generic GNU/linux build (no matters what distribution you have )

you can see as example, there is another build-ubuntu.xml, that make all ubunut's version config/package.

you could ( i can help you ) have your own  build-fedora.xml file, and i'll host it in svn if you want.

so there you can set all rules that you need.

the build script have 2 steps:
* build ( compiles all .java files to .class )
  --> then call build of build-[dist].xml 
* package ( here is when tuxguitar.jar is created )
  --> then call package of build-[dist].xml 

at build time you can:
+ copy every files you want to build/ folder that later will be included in tuxguitar.jar.
+ create your custom launcher

at package time.. well if you don't use it to make the .rpm file it's not really needed. ( in build-ubunut.xml i create there the .deb package )

So if you need a custom one, we can have it.
just copy the best reference..
see build-linux.xml to  build-fedora.xml, and start modifyng it.


> That's a good idea! Better than my patch.

Use the patch for now.. wait these changes for next release.


> Exactly. But, right at this point, if you go to Tools->Settings->Sound, you
> will see that TG Fluidsynth[sf3] is selected as the Midi Port. But it is only
> effective when you restart the sound backend of tuxguitar.  

it's not really selected..
you see it selected on the window, because there is no a  " -- Please Select -- " option.
so when nothing is selected.. you see first available as default preselected in the window (but not in the application ).

Now, if you close the app, and start it.. the application try to load the first port that if found, so in this case yes it must start sound with it.

These Fluidsynth ports, are.. how to say.. some kind of "info" ports.
the plugin, only opens one fluidsynth instance.
when you select the MIDI Port, what it does, is tell fluidsynth "hey, load this soundfont"
this is why when you remove the soundfont, the port continue sounding..
because these soundfonts you add/remove are only info to later displays in MIDI Port combo.
now if you disable the plugin then yes, application will stop sounding.

maybe i have to add a more intuitive interface for these things..

Comment 42 Jon Escombe 2009-11-27 00:16:59 UTC
Just my 2p worth, but I'd vote for the pulseaudio driver as being the right default choice for Fedora. 

Setting it to alsa isn't going to buy 99% of users anything, as it'll still get routed through PA. And even if they kill PA, it'll auto-start when they access the default alsa device.

As an aside, if the minimum PA latency is really too much for you, you can easily suspend it's access to the underlying alsa device and then it's yours to use directly. Although to be honest I can't see that 50ms or so would be noticeable for tuxguitar... 

Anyway, that's just my opinion. Keep up the good work! ;)

Comment 43 Orcan Ogetbil 2009-11-27 07:06:38 UTC
Created attachment 374154 [details]
build-fedora.xml

Julian, I made a build-fedora.xml file by looking at the other files. I tested this and it seems good. Could you add it to the trunk?

Comment 44 Julian Casadesus 2009-11-27 13:30:16 UTC
(In reply to comment #43)

I commited it:
http://tuxguitar.svn.sourceforge.net/viewvc/tuxguitar/trunk/TuxGuitar/xml/build-fedora.xml?revision=771&view=markup

Then you can give me your defaults settings to use it, so i can add them at build.properties.


(In reply to comment #42)

> Just my 2p worth, but I'd vote for the pulseaudio driver as being the right
> default choice for Fedora. 

I still think that in the future we have to make a nice script that check that (not for fedora.. for all distributions ).
Just check running daemons in this order: Pulseaudio, Jackd, ALSA | OSS

Ofcourse we are talking about fluidsynth plugin..
it would be great if we could do this with fluidsynth (or timidity) as ALSA ports. so it will get users MIDI working for all aplications instead only for tuxguitar.

> Although to be honest I can't see that 50ms or so would be
> noticeable for tuxguitar... 

Well, if you are playing an audio file, it isn't a problem.. because the audio is a continuos data.
but MIDI synthesizers generates audio data by each note in realtime. so when you have delays, it could cause bad timing between notes.
However this problem is allmost related to non-realtime kernels.

Comment 45 Jon Escombe 2009-11-27 13:59:19 UTC
> I still think that in the future we have to make a nice script that check that
> (not for fedora.. for all distributions ).
> Just check running daemons in this order: Pulseaudio, Jackd, ALSA | OSS

I'm afraid this check might not work as well as you hope in the future. 

For instance, Pulseaudio might still be running, but have suspended it's access to the audio device you're interested in. I use this approach when I'm using a MIDI keyboard with fluidsynth, as the latency _is_ enough for me to notice in this use case. 

There are also plans for jack and pulseaudio to communicate over dbus, so that pulse lets go of the audio devices automatically when jack wants them. 

I'm sure there must be a way to find out what owns a particular device, but I don't think checking for running processes will be enough..

Comment 46 Julian Casadesus 2009-11-27 17:08:39 UTC
> Pulseaudio might still be running, but have suspended it's 
> access to the audio device you're interested in

You are right, this is why i didn't the script yet :) but i'm sure there should be any way to check this.

In my case, i don't suspend PA, i have pulseaudio configured to use jack as output: Pulseaudio -> Jack -> ALSA..  so pulseaudio and jack are allways running without conflicts.

Comment 47 Orcan Ogetbil 2009-11-28 00:01:04 UTC
(In reply to comment #44)
> 
> I commited it:
> http://tuxguitar.svn.sourceforge.net/viewvc/tuxguitar/trunk/TuxGuitar/xml/build-fedora.xml?revision=771&view=markup
> 
> Then you can give me your defaults settings to use it, so i can add them at
> build.properties.
> 
> 

Thanks! Sure. I build tuxguitar with flags
   -Dpath.tuxguitar=$PWD/TuxGuitar/tuxguitar.jar \
   -Dpath.itext=/usr/share/java/itext.jar \
   -Dpath.swt=$LIBDIR/java/swt.jar \
   -Dlib.swt.jar=$LIBDIR/java/swt.jar \
   -Ddist.lib.path=$LIBDIR/tuxguitar/ \
   -Ddist.file=xml/build-fedora.xml \
   -Ddist.jar.path=/usr/share/tuxguitar/ \
   -Ddist.share.path=/usr/share/tuxguitar/ \
   -Dos.lib.suffix=$SUFFIX \
   -Dos.data.dir=/usr/share/ \
   -Ddist.default.style=Lavender \
   -Ddist.default.song=/usr/share/tuxguitar/tuxguitar.tg"
   -Dos.bin.dir=/usr/bin \
   -Ddist.doc.path=/usr/share/doc/tuxguitar-$VERSION/ \
   -Ddist.dst.path=$RPM_BUILD_ROOT"

Here $LIBDIR = /usr/lib or /usr/lib64
     $SUFFIX = "" or "64"
are calculated in the spec file before executing ant. Some of these flags probably conflict with your default flags but the others can be added to build.properties.

> (In reply to comment #42)
> 
> > Just my 2p worth, but I'd vote for the pulseaudio driver as being the right
> > default choice for Fedora. 
> 
> I still think that in the future we have to make a nice script that check that
> (not for fedora.. for all distributions ).
> Just check running daemons in this order: Pulseaudio, Jackd, ALSA | OSS
> 
> Ofcourse we are talking about fluidsynth plugin..
> it would be great if we could do this with fluidsynth (or timidity) as ALSA
> ports. so it will get users MIDI working for all aplications instead only for
> tuxguitar.
> 

Another issue is we don't have fluidsynth compiled with pulseaudio support in Fedora. There was a long debate about this recently in FESCo (our steering committee). The long story short:
I am also a comaintainer of our fluidsynth package in Fedora. We have a large selection of packages for audio production in Fedora which work in harmony, thanks to jack. I did not want to introduce pulseaudio into our audio production stack because pulseaudio is not supposed to be used for audio production in the first place, and I don't want to deal with bugs filed against fluidsynth caused by pulseaudio. But FESCo's decided that we need pulseaudio support in fluidsynth because certain non-production software is using fluidsynth too (for instance tuxguitar can be used for non-production purposes). FESCo assigned someone to take care of the pulseaudio originated bugs in fluidsynth using applications. So at some point, we will have fludisynth with pulseaudio support.


On the other hand, writing a detection script is not that easy as you said. Jack and pulseaudio run as userspace daemons, but oss and alsa run globally.
But if there is a working jackd daemon, that means that the user knows how to use jack, and such users will probably prefer jack over everything. In this case tuxguitar's fluidsynth can use jack.


By the way, when I use tuxguitar's fluidsynth with jack, tuxguitar's fluidsynth output is not automatically connected to system input. Is there a way to change this to make it automatically connect it to system input port?

Comment 48 Julian Casadesus 2009-11-28 13:32:32 UTC
(In reply to comment #47)

> Here $LIBDIR = /usr/lib or /usr/lib64
>      $SUFFIX = "" or "64"
> are calculated in the spec file before executing ant. Some of these flags
> probably conflict with your default flags but the others can be added to
> build.properties.

Ok thanks, don't worry for these conflicts.. it's just for users that are not going to build the rpm, but the build-fedora script.

> Another issue is we don't have fluidsynth compiled with pulseaudio support in
> Fedora.
So forget about my suggestion of using PA driver :P


> On the other hand, writing a detection script is not that easy as you said.
No no, i never said that it's easy.. i just say that it have to be possible.
note that while i say script, i have no the english (i speak spanish) words to describe what i think.. i'm thinking on something.. it could be a script, a binary application, or both. 

> Jack and pulseaudio run as userspace daemons, but oss and alsa run globally.
The idea is that this script will run in userspace at run time (not at install time) every time you launch the application, so the scrip will also run in userspace.
ofcourse that this thing will not be perfect.. but i think it will give sound working as default for a lot of users ( these users that currently now just can't heard any sound )

I never investigate it's sources, but i'm really sure that gstreamer does what i say. really, i don't remember had to configure gstreamer to play sounds.. if i have PA runing, it send audio to PA, if i don't have it, it send audio to ALSA.. conclussion, it works as default. this is exactly what i want.

> But if there is a working jackd daemon, that means that the user knows how to
> use jack, and such users will probably prefer jack over everything. In this
> case tuxguitar's fluidsynth can use jack.
Yes i agree, this is the easy part.. once we detect all running sound systems, then we can define the priorities.


> By the way, when I use tuxguitar's fluidsynth with jack, tuxguitar's fluidsynth
> output is not automatically connected to system input. Is there a way to change
> this to make it automatically connect it to system input port?  

Not yet, it's not implemented in the plugin. but i have planned to do.
currently now the plugin settings are dynamic ( list all options that fluidsynth give us ).
but each audio.driver, midi.driver may have extra parameters.
so we have to hardcode there (i'd like it dynamic too) 
is user selected jack, so display static jack options ( autoconnect, multiple channels, etc )
if user selected file, so it's satic options ( output file name )..

I'm looking for a dynamic way to do this, so if a new fluidsynth version is released with new drivers ( or existent changes ) we don't have to re-hardcode the options.

I also had planned to add the possibility to send raw params to fluidsynth.
so if the plugin don't supports anything, you can manually fill that params:
fluidsynt.param=Your Custom Value

Currently now the only way i know, is if you are using qjackctl, configuring the connection with Patchbay option. (i'm not really sure if patchbay is from qjackctl or if it's from jack, providing any command line for it )

Comment 49 Simon Gardner 2021-10-19 10:43:45 UTC Comment hidden (spam)

Note You need to log in before you can comment on or make changes to this bug.