mpdcron is a ‘cron’ like program for mpd.  It can execute scripts based on mpd’s idle events.

You can specify this in a very simple config file.  You first list the event it should react on, then the command it should execute. You can let one script respond to multiple events by combining them with a pile. (Like you would in C)

For example an entry like this:

OPTIONS|MIXER  /home/qball/scripts/mpd_control_mixer_changed.sh

The script mpd_control_mixer_changed.sh is called when either options changed (f.e. random, repeat etc.) or the mixer changed f.e. volume levels.

The following events are available:

DATABASE: The database changed.

STORE_PLAYLIST: One or more stored playlists are modified/created/deleted.

QUEUE: The play-queue changed.

PLAYER: The state of the player changed. f.e. stopped/paused or the song changed.

MIXER: The volume mixer changed.

OUPUT: One or more outputs got enabled/disabled.

OPTIONS: Repeat/Random or another option has changed.

UPDATE: The database started or stopped updating.

The config file can contain an arbitrary number of lines.

It takes the following command line parameters:

One or more config files. If none is specified it tries ~/.mpdcron

-f: Run in foreground

–hostname=<name>: Set hostname

–port=<port>: Set the port number

–help/-h: Print help message

It also responds to the MPD_HOST/MPD_PORT environment variable.

The program uses MPD’s idle command. So it does not poll or anything, it just waits for mpd to notify it off a change.  It  should be very lightweight and low on resources.

Dependencies: libmpdclient 2.0

It is currently available in git (http://repo.or.cz/w/mpdcron.git ), in the mpd-trunk ppa (ubuntu) or as AUR package (archlinux).

F.e. I say “It does not perform better then 12 bit”.

What I mean by this is the following:

If you turn an analog signal into a digital signal, you introduce errors, because you only have X defined levels, not infite as with analog.

So the more bits you have, the more levels you have, the less noise you introduce. The error that you make is 1/2 an LSB (least significant bit).  Any noise in the system larger then this 1/2 LSB can cause that the outputted value does not represent your input value.

This gives you a maximum noise your system may have if you want to output X bit signal. (It must be smaller then 1/2 a step, so in 8bit (256 levels) your noise should be lower then 1/512 of the maximum value)

So if your soundcard has a -80dB SNR (signal to noise) you can calculate  how many bits this can maximal represent, any more bits will be “lost” in the noise.

A rule of thumb is: ENOB = (SNR(dB) – 1.76)/6.02 (f.e. see Intergrated converters by Paul G.A. Jespers).

So if you have the 80dB SNR you can represent an ENOB(exact number of bits) of almost 13 bits.  Any more bits, are smaller then the noise and cannot be represented.

If you look at a common onboard soundcard spec, you get an SNR of the 86db, so 14 bit. But this is static, your dynamic performance is often even worse.

For example the realtek ALC850 Chip (used on older asus motherboards) has an SNR of 86dB, 14 bit. But it dynamic performance is 70dB, that is only 11bit! In real life it might be even worse, because noise from your PSU is also added, this realtek supresses the noise by only 40dB.

To compare, to correctly represent a CD you need 98dB SNR static and dynamic.

This, in short and with some simplifications, is why most onboard soundcards suck.

So if your resampler makes -80dB noise, with this soundcard, you hardly need to care about it.

Q

p.s. To get the more correct full picture, I advice you to get a good book on ADDA converters. like the one by Jespers.

So why high cpu usage playing back music (44.1khz) on a card that supported 44.1khz?
Well a quick look in “/proc/asound”

cat /proc/asound/card0/pcm0p/sub0/hw_params

Showed that the card was in 48khz mode, why?.
After some googling i found this link

I quote:
Dmix by default uses 48kHz sample rate.
What? lets read this again:

Dmix by default uses 48kHz sample rate.
ok it really sais it. So even if you are playing 44.1khz sound, on a card that supports 44.1khz it resamples it to 48khz. That is bad.

Why is resampling bad? well 2 things:
1. It is lossy, espicialy 44.1->48khz as it is irrational conversion. (see your favorite DSP book)
2. It takes lot of cpu. The better you want the conversion, the more cpu it takes. The internal resampler of alsa does not use a lot of cpu, but is terrible. If you let mpd resample using libsamplerate it will cost you 10-30% cpu. depending on your machine.

So how to solve it?

There are several solutions, 2 are obvious:
1. Let mpd bypass dmix. You can do this by setting plughw:0,0 (for the first soundcard, first output). However if mpd is playing, nothing can else can use the soundcard. You don’t have mixing anymore. (unless your soundcard supports this in hardware)

2. Force dmix to use 44.1khz.

Lets see the inpack of all this by setting up a test case on my aspire one laptop:

The souncard supports (following /etc/asound/card0/codec#0) 44.1khz to 192khz for 16,20 and 24 bits. So 44.1khz playback should not be a problem, great.

So lets install mpd (I took the latest snapshot from git), use default config (I haven’t changed anything) and play some music (a 44.1khz 16bit flac rip from the album “slowhand” by “Eric Clapton”).

A quick look in /proc/asound/card0/pcm0p/sub0/hw_params showed that I was playing 32bit 48khz. (From the 32bit only the highest 24bits are used, for more explanation about this see the alsa documentation).

My cpu usage is 4-8%.    I cannot judge quality, this soundcard actual performance  is around 12-13bits. So any imperfections I hear are the soundcard, not the resampling.

Now this uses the bad crapppy internal resampler of alsa, so let mpd resample. This can be done by setting auto_resample “no” in my alsa audio_output block. I do have lsr installed, and use the default settings.

New cpu usage is 12-17%.

But the real solution in this case would be to stop the resampling.  Because I still want to be able to “mix” sounds. So lets try solution 2;  trie to change dmix default sample rate.

This is done by adding the following to my /etc/asound.conf

pcm.!default {
type plug
slave.pcm {
type dmix
ipc_key 1024
slave {
pcm “hw:0,0″
rate 44100
}
}
}

This should make my dmix play at 44.1khz. Lets restart mpd (yes this is required somehow) and play a song, checking /proc/asound/.. entry showed it was actually playing at 44.1khz GREAT!.

The cpu usage is now dropped to 1-2 % on a intel atom running at 800mhz. That is a massife improvement. And you did not loose sound quality this time.

There is a negative side to this solution, trying to play 48khz audio, it will be down-sampled to 44.1khz. This happens when playing a dvd.

I don’t mind, if I play a dvd (that has 48khz audio), I can either bypass dmix, or resample. The quality loss is not what I care about when watching a movie, I cannot even hear it on this crappy soundcard. The extra cpu usage is also not an issue, as the cpu is under a greater load by the playback of the video.

I hope this explains (and help solve) the high-cpu usage problem with mpd.

Q

• Add check for mpd version. If it is to low give an error and disconnect.
• Fix dependency.
• Small gui update.
• Polish translation.

Download

Get them from this directory: [here]

New Features

• Rewritten current playlist backend.
• Improved playlist validation
• Player part of the player cleaned up, including the mini-mode.
• Better collection detection for album art.
• Allow reordering of the left pane by drag and drop.
• Improved search as you type in the play queue.
• Database and playlist search browser merged.
• Tokenized search in search browser.
• Improved tag browser
• Incemental filtering of columns.
• Directly editing of column type.
• Better art support.
• Search as you type in the columns.
• Metadata browser speedups.
• On many requests, re-adding of the stop button the main interface.
• Correctly track output state.
• Tooltip on song list showing details about the song.

Alot of cleanups are done, duplicate code is removed and where possible stock-widgets are used.

Removed Features

• Playlist queue’s: This feature was removed from mpd, so gmpc follows.

Download

Get them from this directory: [here]

pcm.convert {
type plug
slave convert
}


Every time I reinstall (or in this case disable pulse audio because of problems) I forget how I have to configure it.
this works, if you set device “convert” in mpd config.

1. Stops mpd from hanging if you try to stop it when buffering a seekable stream. (for some reason ogg tries to skip through a large part of the file when opening it, when it has random access. and this caused problems when during this opening the stream is closed). bug 1611.
2. Somewhat related, when the network connection stop responding (Resource temporarily unavailable error) don’t wait for ever to come back. Give it 100 tries (this is a relatively short time) and then give up.
This seems to fix some other bugs. Like: 1558.

Last week I fixed the parsing of id3tags, there was an error that caused comment tags not to be parsed. #1615
This week I fixed replaygain for libflac version > 1.1.2 #1616. This was a small one, so I might try to do another one.

But after putting a hard-disk from an old external hddcase into the mac mini I had it running again and I found out that mpd (and even snapshots from svn) are now available in mac-ports.

In other news, gmpc now has an itunes like tag browser, it’s completely configurable. I didn’t wanted to write it, but the tag editor wasn’t used allot and this was requested many times.

Qball

The fun part is, you hardly notice that gmpc is working with this many songs. also the memory usage seems to be under control.
I registered a use of 32mb in htop.. (compared to 649mb of sonata, and more then 60mb of ncmpc on the same list)

I also made a small video to show it.. but it goes a bit less smooth because xvidcap was using all the cpu time:
The video

p.s. don’t try it in rhythmbox or banshee… trust me it aint fun..