Stephan Sokolow's Blog

Note: This is still fragile, so I can’t help you if it doesn’t work on your system.

I finally got around to trying OSS 4 and I just can’t go back to ALSA. Not only is it less cantankerous, the mixer curve I get by leaving my soundcard on defaults and adjusting the vmix in-kernel mixer is much nicer.

Unfortunately, there was one problem. MIDI support for OSS 4 is still in development and I have old Windows games which use MIDI for their background music. With ALSA, I had been using Timidity as a software synth that Wine could hook into, but I couldn’t get that to work with libsalsa (the OSS 4 ALSA compatibility layer) so I decided to look for an alternative.

It’s a jerry-rig, but I figured out how to strap the ALSA userland onto OSS 4 so that Wine has a way to get MIDI events to Timidity. Details below…

Step 1: Install OSS

(Remember to symlink /dev/dsp to your preferred /dev/dspN if it forgets.)

Make sure alsa-lib (or your equivalent) stays installed and that the lines in /usr/sbin/soundon
for setting up libsalsa are commented out. (The ebuild on bugs.gentoo.org which I used comes with a patch to
do this)

If you want to do this yourself, find the line which says “# Use library based ALSA compatibility”
and comment out the block which follows it. If you don’t know how to do this, I suggest grabbing
the patch from bugs.gentoo.org.

If you want to use the ebuild, it’s at Bug 184123.

Step 2: Create an /etc/asound.conf

It should contain only the following:

pcm.!default {
        type oss
        device /dev/dsp
}

Step 3: Set up your ALSA kernel modules

Set up the following ALSA config in your kernel:

Device Drivers --> Sound -->
	<M> Sound card support
	Advanced Linux Sound Architecture  --->
		<M> Advanced Linux Sound Architecture
		<M>   Sequencer support
		[*]   Support old ALSA API

The following were something I tested but didn’t see any difference to. Your mileage may vary.

		<M>   RTC Timer support
		[*]     Use RTC as default sequencer timer

Everything else should be disabled.

Step 4: Adjust your init scripts

Make sure your init scripts successfully load OSS 4 and then adjust them to run “modprobe snd-seq” after it has checked and found no ALSA.

Step 5: Set up Timidity

This part took the the longest to figure out. Timidity is VERY fickle in this setup, so your mileage may vary. Here’s what I had to do:

• Timidity had to be run from inside my KDE session. (not from an initscript)
• I had to use artsdsp and set Timidity to use ALSA output

The command I used was “artsdsp timidity -iA -Os” but the -Os was just to make sure. (It was default on my system)

The second-best I found was “timidity -iA -Op” (Portaudio output without artsdsp) and it could be run from an initscript, but it would go silent after the first song or two.

Plain ordinary ALSA output had a similar problem, but also had timing glitches. Ironically, when Timidity is just playing a midi file directly as opposed to receiving MIDI events via ALSA, the timing glitches are absent.

For those who aren’t familiar with git, I’ll start with a short summary. Git is the version control system that Linus Torvalds wrote when none of the existing alternatives were acceptable choices. Short enough?

Now, here’s why you should be using it: (Keep in mind that I realized this so recently that I’m still using Bazaar with a handful of Subversion repos still on the conversion TODO list)

• Git is VERY fast… subsecond-response fast. Torvalds wrote it that way so he could get response times of a few seconds when working on the Linux kernel, which has a big tree.
• Git is distributed. Every working copy doubles as a repository in full, so you can work offline just as easily as online and every time someone clones your source tree, they also make a backup of your repository.
• Git doesn’t just take care of your data, it protects it. Unlike many other revision control systems, Git will notice and inform you of corruption due to faulty hardware. Then you can just pull a good copy from a co-worker, your public repo, or a user who likes to live on the bleeding edge. Every commit uses SHA1 hashes to ensure the integrity of both the newest commit, and all prior commits. (which also foils anyone might try to edit an old revision of the code for nefarious purposes)
• Git makes it comfortable and easy to branch and merge as much as you want.
• Git’s command-line interface is actually comfortable. Commands like `git stash` and `git commit` are designed by programmers for programmers.

Aside from it’s speed, that last point is actually the most important for me (I’m horrendously lazy) and, ironically, the one that I didn’t discover until I actually tried it. As such, let me explain what that means in more detail:

First, `git commit`. In most version control systems, the “add” subcommand (`git add`, `svn add`, etc.) tells the tool to start monitoring the files for changes which will be automatically committed by the “commit” subcommand. In git, you have to run “git add” every time you want “git commit” to pick up some changes. Confused? Good, now I’ll explain why this is a good thing.

to get the usual behaviour you’d expect from something like Subversion, Bazaar, and the like, you can run “git commit -a” (-a being shorthand for –all. I’ve used the git config file to alias it to `git ci` for comfort) but what if you’ve been happily hacking away at two different pieces of your program (Let’s call them “bob” and “steve”) and want to commit them separately?

That’s where git’s different approach suddenly makes sense. Commiting them separately is simple and comfortable…
$ git add bob/
$ git commit
...type in your description for bob's changes...
$ git add steve_*.c
$ git commit
...type in your description to steve's changes...

As with so many things in Git, it’s an example of a non-obvious but simple change which makes your life immeasurably more comfortable.

Second, `git stash`. This one is a much simpler. What if you’ve been coding away at something and, before your changes are ready to apply, someone (eg. your boss) rushes in and tells you to fix HEAD (the newest commited version) immediately? Without “stash”, it’ll take you at least six commands to temporarily “stash” your changes so you can work on HEAD without losing them. With stash, it takes just three and they’re easy to remember: (As taken from the stash manual)
$ git stash
... make the emergency fix ...
$ git commit -a -m "Emergency fix for the FOO problem"
$ git stash apply


Simple, easy to remember, and fast… just like the rest of git these days. Don’t take my word for it, drop by the git website and check out the crash courses yourself?

Of course, don’t let that stop you from using Zack Rusin’s Git Cheat Sheet. It’s always nice to have a quick reference card handy, after all.

UPDATE: As a Linux user, I almost forgot to mention that yes, the Windows port is quite usable. The big scary warnings are actually mainly messages that can be summed up as “Windows doesn’t have this feature that Linux git users might be used to”. There’s a slightly aged GMANE thread you can check if you want more details.