Tuesday Feb 09, 2010

Installing and running Fluidsynth on OpenSolaris

I'm a sucker for a good multimedia package.  I love playing with software that does movie playback on encoding, audio playback, transcoding...you name it, I love playing with it.  So naturally I was pretty psyched to see that somebody has contributed the Fluidsynth software synthesizer package to OpenSolaris.  Here is what I did to install it and run it in order to prove that the package actually works.  (here's a spoiler for you: it does work.)

Fluidsynth was put into the OpenSolaris "pending" repository, the idea being that people will check it out and if it's deemed to be of reasonable quality, it'll get voted into the contributed software repository.  The "contrib" repo is where good packages go after they've been testing in the "pending" repo staging area.  We haven't voted on Fluidsynth yet as of the time I write this; I'm hoping that will change after people read what I've done here.

(note: for my testing, I am running OpenSolaris build snv_111b)

First things first: set up OpenSolaris to find packages from the Source Juicer "pending" repository with these two steps:
  1. type "pfexec pkg set-publisher -O http://jucr.opensolaris.org/pending jucr-pending"
  2. type "pfexec pkg refresh"
Next, I launched the Package Manager application and chose the "jucr-pending" repository from the pop-up menu on the right side of that application's user interface.  After Package Manager thought about its new catalog of apps for a moment, I saw a list of hundreds of packages available to me.  I used the search field to type "fluid", and found the "fluidsynth" package.  Selected that, saw that it lists several other packages as dependencies (i.e., those other packages had better be installed for Fluidsynth to work correctly), then I installed it.  Nicely, the Package Manager installed Fluidsynth and its dependent packages for me.

At this point I ran into a little snag, which is not the fault of OpenSolaris: I'm testing this within OpenSolaris, but OpenSolaris is running as a VirtualBox guest on my Mac Book Pro.  Turns out that audio support in OpenSolaris under VirtualBox needs a little bit of work to get going.  It's easy enough, though, and took less than five minutes to get it working.  The instructions on how to make it work are in this blog post, which is clearly written.  And I had fewer problems than were mentioned; I didn't have to reboot or uninstall the "SUNWaudiohd" package.  Good times!

At this point, my big challenge was where to find two files to test Fluidsynth: a sound font (basically, a description of instruments that Fluidsynth uses to play music), and some music (a MIDI file).  I did a Google search to find a nice Yamaha DX-7 electric piano sound font (I happened to find it here), and it was easy to find any number of .mid files to play.

To test, I typed "fluidsynth <name-of-sound-font.SF> <name-of-MIDI-file.mid>".  That worked just fine: I heard the music loud and clear, although Fluidsynth complained that there is no /dev/midi.  I believe it is expecting me to connect a MIDI keyboard to the computer and start playing, which is not necessary for this test.  Also, Fluidsynth had to re-map some of the MIDI file's preferred instruments to what was available in the sound font's instrument library.  Not a problem, though.

Just for fun, I tried turning off the built-in chorus and reverb effects, and I boosted the amplitude to see if these features worked:

"fluidsynth --chorus no --reverb no --gain 0.8 <name-of-sound-font.SF> <name-of-MIDI-file.mid>".  I also tried changing these parameters individually to isolate the effects.  Again, this worked fine.

As far as I can tell, Fluidsynth works perfectly well on OpenSolaris.  It should make a fine addition to the contrib repo.

Powered by ScribeFire.

Friday Nov 06, 2009

Installing and running Ruby-rack on OpenSolaris

Rack is a webserver interface for the Ruby open source programming environment.  Amanda Waite took the trouble of making this package available via the OpenSolaris packaging mechanism; ultimately, ruby-rack will be in the OpenSolaris "contrib" repository, but not until it gets a little testing and review, and some votes from the community, this functionality is now in the OpenSolaris "pending" repository.  I admit to great naivete about Ruby, so I'll refer you to this excellent explanation of what Rack does for Ruby developers.  (my summary of what I got from the explanation: Rack is a web framework for Ruby developers; in other words, if you like writing Ruby code and you want to write code to create a web-based application, Rack is a nice extension to Ruby to make doing this easy).

Anyway, been doing some testing of the package that Amanda submitted.  Here's what I did and what I observed:

First, I made sure I had access to the OpenSolaris Source Juicer "pending" repository.  As I've noted before, two steps:
  1. type "pfexec pkg set-publisher -O http://jucr.opensolaris.org/pending jucr-pending"
  2. type "pfexec pkg refresh"
After that, the next time you launch the Package Manager application, look on the right side of the application and you can choose "jucr-pending" from the pop-up menu.  Do that, and after a moment you'll see a list of all the packages in the "pending" repository.  You will find the package "ruby-rack" there.  Note that case matters; the package name is all lowercase.

So I did this and downloaded the package.  The package notes that it depends on the Ruby package.  The Package Manager pulled it in just fine.  How do I know?  Before installation, I could not type "ruby" and get anything back.  Afterward, it worked.

Next step:

$ cd /usr/ruby/1.8/lib/ruby/gems/1.8/gems/rack-1.0.1/example
$ rackup lobster.ru

This starts a web server on port 9292 with a little "lobster" program.  I launch the web browser and go to "http://localhost:9292" and I saw a simple web app that shows a crude "picture" of a lobster, and two things I can do: flip the lobster from right to left and back again, and show a crash dump of the Ruby Rack program.  I tried both of those things; they worked just fine.

After this, I killed the "rackup" program then tried it again with the other ".ru" file in that same directory, "protectedlobster.ru".  That gives an added feature of authenticating into the web app (password is "secret"; as far as I can tell, use any username you wish).  That worked, too: if I didn't provide the right password, nothing happened.  If I provided the right password, it worked fine.

So that all worked just fine.  The next set of tests was more in-depth, running a partial test suite.  For this set of steps, I had to install both the "SUNWgcc" and "SUNWgmake" packages, again with the Package Manager.  I did these steps:
  1. su - (i.e., pretend you're root; without doing this, step 3 below complained that it couldn't write to /var/ruby/1.8/gem_home/bin)
  2. Add /var/ruby/1.8/gem_home/bin to your $PATH
  3. type CXX=/usr/sfw/bin/g++ gem install memcache-client ruby-openid camping mongrel thin test-spec --no-ri --no-rdoc
  4. type "gem install rake"
  5. type "rake test".
The output showed it compiling some stuff, then it said "Started" followed by a bunch of periods showing status, then "Finish in 3.960495 seconds."  Finally, a results line said "267 tests, 928 assertions, 0 failures, 0 errors".

That sounds like good news to me!

So folks: the Ruby Rack web framework is available via OpenSolaris.  Check it out and see if it works for you, Ruby developers.  Let us know how it goes, will ya?

Powered by ScribeFire.

Wednesday Oct 14, 2009

Update: Drupal now available in OpenSolaris

Sun's ISV Engineering group has been working hard all spring and summer to get fistfuls of popular and important open source applications into the OpenSolaris "contrib" repository, a repo for third-party applications that can be assumed to have some level of sanity checking done on them.

Eric Reid in ISV Engineering has submitted three different releases of Drupal; today, the final release (Acquia Drupal) was approved and placed into /contrib.  These three applications are
  1. Drupal 5 (release 5.20)
  2. Drupal 6 (release 6.14)
  3. Acquia Drupal, created by the commercial enterprise backing Drupal: Acquia.com
It's nice and easy to try out any of these Drupal packages in OpenSolaris.  Want help?  Read this entry on drupal.org for complete yet succinct instructions.

I should also point out that when you install Drupal in OpenSolaris, the package management system will pull in the Sun WebStack components automatically, which is all free as you would expect.  It's the AMP stack components you know and love, but optimized by Sun for out-of-the-box performance improvement, plus a management console that lets you see what's going on with the components while you're running your Drupal web site.

(Okay, that may have sounded a bit like an advertisement, but we really did put a lot of engineering effort into optimizing the AMP components on Sun's systems and the new analytics thingy is pretty cool looking.)

Meanwhile, this adds one of the premier open source content management systems to the stable of apps freely and easily available to you when you install OpenSolaris on your computer.  You can even choose from amongst the leaders in blog engines / content management systems / web site building tools: Drupal, Joomla!, WordPress are all available now.  Here is a list of packages published to the contrib repository.

Check 'em out!

Powered by ScribeFire.

Tuesday May 12, 2009

Note to self: installing OpenSolaris packages from the SourceJuicer

The SourceJuicer is a tool in OpenSolaris meant to simplify the process of getting apps onto OpenSolaris.  The tool works by taking a file specifying the contents of the package to be installed (called a "spec file"); this includes information on where to fetch the source code for the application package, directions on how to build from source, then where to install the resulting app.

Ultimately, packages built using SourceJuicer will be reviewed and voted into the "/contrib" repository, a repo for third-party applications not necessarily part of the OpenSolaris core distribution.  SourceJuicer puts the packages it builds into a repo called "/pending"; to test these apps, you need to tell the package manager where the /pending repository is.

I want to take my OpenSolaris 2008.11 distribution and play with some of the new packages in /pending.  For example, I want to try the Azureus (now called Vuze) BitTorrent Java application which somebody just made available on OpenSolaris.  To do so, I need to do the following steps:

  • Add the SourceJuicer "/pending" repo to the list of repo's known to the package manager:
  • $ pfexec pkg set-authority -O http://jucr.opensolaris.org/pending jucrpending
  • Now I can install the package I want (in this case, "vuze", the name of the Azureus/Vuze application):
  • $ pfexec pkg install vuze
Simple as that.

I can also add this package repo and install the package via the graphical "Package Manager" interface, available via the menu choice System -> Administration -> Package Manager.  Once the Package Manager is launched, I choose the menu choice "Settings -> Manage Repositories..." to add the SourceJuicer pending repo.

Powered by ScribeFire.


The views expressed on this blog are my own and do not necessarily reflect the views of Oracle. What more do you need to know, really?


« July 2016