corn

Corn is a small^* music playing daemon. It strikes a balance between nerdy programmable flexibility and modern desktop integration.

key features

Uses libxine for playback -- supports the many file formats that xine does.
Uses D-BUS and the MPRIS standard for inter-process communication.
Scriptable via any language with D-BUS bindings, or via mpris-remote on the command line, and compatible with a number of other MPRIS-speaking programs and libraries.
Uses GIO/GVFS to access media files locally or through a number of protocols. (SFTP, HTTP, FTP, WebDAV, SMB, inside of gzipped/bzipped tarballs)
Uses SQLite for metadata storage. Stores all metadata but scans it lazily, so importing music and beginning playback is fast.
Is fairly small and simple, especially for a program in C: around 2000 lines of code.

useful links

download/build/install instructions
compatible programs/utilities/libraries
API reference
bug tracker
discussion mailing list

Corn is a fork of Quark.

never-asked-but-anticipated questions

don't have a dbus session bus running?

If you use startx with a smaller window manager instead of a full blown desktop environment, you may not have a dbus session bus running. The system bus (dbus-daemon --system in your ps output) will not do -- it is not for communication between user apps. To get a session bus running, put this in your .xinitrc:

if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then
    eval `dbus-launch --sh-syntax --exit-with-session`
fi

selecting an audio driver

For me, libxine by default tries to connect to a pulse audio daemon with a timeout, which caused a startup delay for corn. But corn has its own xine config file, which is at ~/.config/corn/xine_config. You can just symlink it to ~/.xine/config if you want corn to use the same libxine settings as the xine program, or it can be its own separate file. Here is my xine_config:

audio.driver:alsa
engine.decoder_priorities.mad:1000

^*well, depends on what you mean by small

Corn actually uses kind of a lot of memory right now (60-80MB for me). This is a libxine problem, apparently due to it allocating tons of unnecessary buffers. Supposedly it will be fixed sometime. But even until then -- hey -- 80MB is only about 4% of 2GB!

What I really care about when it comes to smallness is the size and complexity of the code.