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

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

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.