Launch Jack Audio Connection Kit daemon with realtime scheduling

Today, it is very simple to launch the Jack Audio Connection Kit daemon with realtime scheduling, with a no-root user.
When Jack Audio Connection Kit is installed, it adds specific "limit" to jackuser group, into Pluggable Authentication Modules (pam).
Cf. the /etc/security/limits.conf file.

So the only need is to add the user which must need to launch the Jack Audio Connection Kit daemon with realtime scheduling into the jackuser group:
/usr/sbin/usermod -G jackuser "username"

Then, use the -R option when launching Jack Audio Connection Kit daemon:
jackd -R ...

N.B.: those instructions have been performed (at least) under Fedora 8

Use MIDI software "soundfonts mapping"

This is a quick "how to", to use softwares installed like explained on this post:
- launch Jack Audio Connection Kit daemon with options according to your configuration (let's said you are using ALSA)
jackd -R -d alsa
The -R option is used for "real-time", I explain it into my next post.
- launch a fluidsynth GUI frontend
qsynth
- setup the wished soundfonts (there we're using the path of the fluid R3 soundfonts), setup->Soundfonts->Open and selects the path /usr/share/soundfonts/FluidR3_GM.SF2 (under Fedora 8),
- finally launch Rosegarden and play MIDI files or Rosegarden Studio of your choice
rosegarden
- you may need to update configuration of the MIDI devices, Studio->Manage MIDI devices.

N.B.: those instructions have been performed (at least) under Fedora 8

Setup MIDI software "soundfonts mapping" (instead of hardware)

In this post, I've (quickly) explained how to set up environment to play MIDI file, loading soundfonts into wavetable of the sound card.
Nevertheless, the soundfonts which can be loaded into the sound card is obviously limited to available memory and so compromise must be done between quality and size.

Instead of this, it is possible to use software "soundfonts mapping". Today, there is lots of very powerful and mature softwares although all must be set up with caution to avoid latency issue.
There is various interesting explanations on the subject, for instance Planet CCRMA at home, and Linux MAO.

This is the software which an be used (prefixed by corresponding package name under Fedora):
- jack (Jack Audio Connection Kit): a low-latency audio server,
- qjackctl: a simple application to control the JACK sound server,
- fluidsynth: a real-time software synthesizer based on the SoundFont 2 specifications,
- qsynth: a fluidsynth GUI front-end application,
- fluid-soundfont-R3: fluid R3 soundfonts of good quality,
- rosegarden4: a professional audio and MIDI sequencer, score editor, and general purpose music composition and editing environment.

N.B.: those instructions have been performed (at least) under Fedora 8

Prepare Fedora environment to become an audio plateform

After some search of interesting tools to play midi musics (with external devices) under GNU/Linux, I finally find an unbelievable project: Planet CCRMA at home.
They provide all needed packages for updating an environment "to transform it into an audio workstation with a low-latency kernel".

There is rich installation information on the official site.

My first aim is to discover the astonishing features of Rosegarden.
To get it fully installed, I have had to install some additional packages XML::Twig and LilyPond:
yum install perl-XML-Twig lilypond

Currently the real-time kernel does not boot on my computer, I'll surely post information about this later ...

N.B.: those instructions have been performed (at least) under Fedora 8

Play MIDI under GNU/Linux with ALSA

There is lots of articles on the subject but it is not so trivial to get needed information to use ALSA tools to play MIDI files.

This is some quick information:
- the first is obviously to have a working ALSA installation,
- if you have several sound cards, ensure the default is well the wanted one (for instance using system-config-soundcard under Fedora),
- then it is important to ensure not having mute channel(s), you can use alsamixer for this,
- then ensure to have a way to load soundfonts into the wavetable of the sound card; for instance of sound card managed AWE32/Emu10k1 sound driver, you can install the awesfx package
yum install awesfx
- get a soundfonts to load, for instance this one,
- at any moment, to check if there is a loaded soundfonts:
cat /proc/asound/card?/wavetableD?
- you can clear currently loaded soundfounts but you want to keep it:
/bin/asfxload -i
- then load it:
/bin/asfxload "soundfonts file path"
- find the "addresses" into the "/proc/asound/card?/wavetableD?" file (for instance: 17:0 17:1 17:2 17:3),
- finally test installation using aplaymidi to play a MIDI file
aplaymidi -p "addresses"* "MIDI file path"
* addresses must be coma separated, 17:0,17:1,17:2,17:3 for instance.

Define the different installed packages between GNU/Linux installations

Let's call one installation local, and the other remote.
On the first one, use rpm to get the list of installed packages:
rpm -qa --qf "%{NAME}.%{ARCH}\n" |sort > /tmp/localInstallationInstalledPackages

Idem, on the second one:
rpm -qa --qf "%{NAME}.%{ARCH}\n" |sort > /tmp/remoteInstallationInstalledPackages

Then, get the differences between each list using diff.

To see the package installed on the local installation, but not on the remote one:
diff /tmp/localInstallationInstalledPackages /tmp/remoteInstallationInstalledPackages |grep "^<"

To see the package installed on the remote installation, but not on the local one:
diff /tmp/localInstallationInstalledPackages /tmp/remoteInstallationInstalledPackages |grep "^>"

In the two cases, to get a list of regarded packages on one line, use the following instructions.
For instance, for the local installation:
diff /tmp/localInstallationInstalledPackages /tmp/remoteInstallationInstalledPackages |grep "^<" |awk '{print $2}' |sed -e 's/$/ /' |tr -d '\n'

Then, you can use this list to [un]install corresponding packages on local or remote installation.

In addition to this post, those instructions allow to get exactly the same installed packages between GNU/Linux installations.

Install the same packages between two GNU/Linux installation, using yum

There is some cases where it is interesting to ensure having the same installed packages between two GNU/Linux installation.
Those installations must be of same architecture and be as near as possible (ideally the same version), otherwise it is obvious it won't work. In addition, it is needed to have the same rpm packages sources (for instance the same repositories if using yum).
For instance, it gives the ability to create a virtual machine with almost the same configuration, and then to perform lots of "tests" (upgradibility ...) without risk (but the one to get a "dead virtual machine") before performing the same instructions on the "original" installation.
Personally, I've used this ability to test upgradibility between Fedora 8 and Fedora 9.
To get the list of installed packages of an installation (including the architecture, which is particularly important there):
rpm -qa --qf "%{NAME}.%{ARCH} " > /tmp/allPackagesList

Then copy the file to the other installation.

Finally, use yum (or something else), to install all those packages (for instance, under GNU/Bash):
yum install $( cat /tmp/allPackagesList )

Such a way, all the packages installed on the first installation, will be installed on the other one.
Nevertheless, there may be other packages already installed on the second one, so the installed packages would not be exactly the same.
I'll write another post to explain how to remove such packages.

Personal Knowledge Base

I've recently used Trac to create a little personal Knowledge Base.
The only aim of this Knowledge Base is to centralize access to various quick information corresponding to specific computer science issues/situations.

Initially, I've set up this system for personal purposes.
Nevertheless, if you find current tickets (Knowledge Base elements) interesting and you wish to add some yourself, send me an email to admin[dot] knowledgeBase[at]bsquare[dot]no-ip[dot]org.

There is currently very few tickets (lack of time), but as soon as possible, I'll add more.

Get sound working with plugins for Firefox or Opera 9 under Fedora 8 (i386 and x86_64)

In addition to plug-ins installation (see this post), it is needed to ensure having an installed soundwrapper to get sound working under a Web Browser.
Whatever the architecture of the OS, it seems absolutely needed to have a i386 installed soundwrapper.
For instance, install the arts (KDE) soundwrapper:
yum install arts.i386

Install multimedia plugins for Opera 9 under Fedora 8 (i386 and x86_64)

There should be no problem to get multimedia plug-ins installed for Opera 9 under Fedora with a "full" i386 or x86_64 architecture installation.
In some cases, this post may help (Opera being "Mozilla compatible" as Firefox) with installation having i386 and x86_64 components.
Nevertheless, other situations may still need additional instructions to be performed.

It was my case with my installation: Opera 9.27 (i386), under a Fedora 8 x86_64 installation.
In particular, the gecko-mediaplayer package (replacing the mplayerplug-in one) was available only in x86_64 architecture. The nspluginwrapper method does not seem to work with Opera, so a i386 version of gecko-mediaplayer package is needed.
This is quick way to get it installed:
- get a i386 version, for instance browsing the livna repository online, or using yumdownloader under a i386 installation,
- install it using yum (it will install all the needed dependencies)
yum localinstall "gecko-mediaplayer-XXX.rpm"
- the i386 plug-ins might be installed under /usr/lib/mozilla/plugins

To enable plug-ins into Opera, follow the usual way:
- Menu Tools->Preferences->Advanced->Content->Plug-in options->Change path
- add the /usr/lib/mozilla/plugins path (or equivalent)
- valid, and then click "Find new..." button.

Close and launch again Opera.
You may use the -debugplugin option to get debug information about plug-ins.

Finally, under Opera, take a look to the "opera:plugins" information page to check if plug-ins are available.

Install Opera 9 under Fedora 8 (i386 and x86_64)

Those instructions might be interesting for other configuration too (for instance Fedora 7 and prior).
The GNU/Linux Opera 9 package does not seem providing all needed dependencies information. Such a way, even if the rpm is well installed, there might be trouble to launch Opera.

To begin, to install Opera:
- download the rpm of the wished version, Opera 9.27 being currently the latest stable one;
- install it with yum to get the maximum (but not all) needed packages installed too:
yum --nogpgcheck localinstall "opera-XXX.rpm"
- ensure to have qt package installed (i386 for v9.27 and prior; x86_64 might be enough for newer version)
- ensure to have a up to date Java installation to benefit from the maximum functionalities (again, i386 for v9.27 and prior; x86_64 might be enough for newer version)
- it might be needed to update the LD_LIBRARY_PATH to specify where to find some libraries: libqt-mt.so (qt), libjvm.so and libawt.so (Java):
For instance, if you have installed the i386 JDK 6u6 under /usr/share/java/jdk1.6.0_06.i386/
export LD_LIBRARY_PATH=/usr/lib64:/usr/lib/qt-3.3/:/usr/share/java/jdk1.6.0_06.i386/jre/lib/i386/client/:/usr/share/java/jdk1.6.0_06.i386/jre/lib/i386/

Compile VMwareTools on Linux kernel 2.6.22

To compile the vmhgfs VMwareTools on Linux kernel 2.6.22, it is needed to patch the source code, like explained there, from a tar.gz installation.
The same fix works from rpm installation, although the VMwareTools source code directory may be different (/usr/lib/vmware-tools/modules/source for me):
- move to /usr/lib/vmware-tools/modules/source/
- untar vmhgfs.tar and backup it
- then follow the same instructions:
"Now edit vmhgfs/driver.c and change lines 44 and 45 from
#define INODE_SET_II_P(inode, info) do { (inode)->u.generic_ip = (info); } while (0)
#define INODE_GET_II_P(inode) ((HgfsInodeInfo *)(inode)->u.generic_ip)
to
#define INODE_SET_II_P(inode, info) do { (inode)->i_private = (info); } while (0)
#define INODE_GET_II_P(inode) ((HgfsInodeInfo *)(inode)->i_private)

Also, remove line 763: inode->i_blksize = HGFS_BLOCKSIZE;
"
- create a new vmhgfs.tar with patched source code
- the compilation can now be fully performed -> launch /usr/bin/vmware-config-tools.pl again