Month: April 2008

Numpty Dumpty

/ alex / 2 Comments

Numpty Physics Dietmar demonstrated the incredibly cool Numpty Physics game on his Maemo device yesterday and I liked it so much that I had to check immediately whether it will compile for plain old x86, too. And, guess what, it works like a charm.

All you have to do is to check out the code from the SVN repository, ensure you have the SDL and SDL-image headers installed change into the trunk directory and run make. If the linker fails for you as it did for me (complaining about X11 symbols), just add an extra -lX11 to the linker command line.

Before you can run NP you will have to create a symbolic link /usr/share/numptyphysics that points to the trunk directory of your SVN checkout. Then run i686/Game and enjoy. Using a mouse to draw items instead of a stylus is obviously not as straight-forward as using the stylus, but it works very well nevertheless.

Update: If you enjoy using bleeding edge compilers you might be interested Adrian’s patch that will make Numpty Physics compile with gcc 4.3.

Visuals

/ alex / Leave a comment

NIN Ghosts The claim that Trent Reznor is singlehandedly fixing the music industry is a bit  far-fetched, but NIN‘s first release after leaving their major label is a very ambitious step in the right direction. Not only is a part of the album available for free and Ghosts a DRM-free download (including a lossless FLAC encoded version), but also is it licensed under Creative Commons Attribution Non-Commercial Share Alike!

When I first bought Ghosts, I was bit disappointed that the tracks have no names – even though I really like the album. Somehow that seemed loveless. But then I learned that this was done on purpose, so that contributors to the NIN YouTube Ghosts Film Festival could start visualizing what they hear from scratch without being influenced by the title of the song. The people out there have contributed more then 600 videos until now and some of them are very well done.

Now if only Google burnt even more money on YouTube – their performance  is really tedious sometimes.

The Return Of The Daemons

/ alex / Leave a comment

There was a time when Linux distributions automatically started sound daemons for the user. Typically these were aRts for KDE and esd for Enlightenment, Gnome and others. The main goal was to allow simultaneous audio playback from multiple applications.

Unfortunately, using these daemons has side effects:

  • they introduce significant latency
  • they require applications to be ported and configured to use them
  • they block the audio device for either serious or rather dumb audio applications

Then, thanks to an tremendous development effort, a new audio layer for Linux was born that addressed the main goal of these daemons, allowing hardware mixing where available and enabling software mixing when necessary. The daemons became obsolete and were eventually removed from the default install of all major distributions. The only daemon that stayed relevant was JACK as it addressed audio production needs and most sound creation tools were extended to support that interface, too.

Now, guess what. There’s a new daemon in town. It’s better than ESD, but will still block your audio device. And from what I’ve read it is not designed to compete with JACK in the ultra-low-latency sector. A major motivation for its creation must have been a severe allergic reaction to ALSA. And Fedora and Ubuntu intend to force it upon us.

I got aware of that after upgrading my laptop to hardy, when mplayer failed to playback audio until I killed the pulseaudio daemon. Oh man, was I happy when the daemons where gone.

Yeah, I know, they promise some interesting features. I also read that PulseAudio is causing significant load under certain conditions. I’m just not sure that you really need an extra CPU hog just to play audio, unless you really dedicate your machine to audio production in which case I cannot see why we should not stick with JACK.

I really wonder whether investing all that energy into improving ALSA instead (and maybe gstreamer or JACK) might have helped to provide some of the same features without the hassle of yet another daemon with yet another API.