I've recently started experimenting with mplayer audio backend for gmusicbrowser as it offers greatly reduced CPU usage compared to gstreamer (mplayer2 uses 0-2 % CPU where gstreamer got 10-20). The biggest annoyance in this switch is the loss of gapless playback. As I understand it, gmusicbrowser currently starts a new mplayer process for each song, killing and restarting it at every track transition, which is responsible for most of the gap. The reason for this was explained in an earlier thread:
Quote from: Quentin Sculo on October 17, 2012, 19:36:52
This is because last time I tried with mplayer in slave mode, I couldn't get a signal (output) telling me that the track was finished. By using one process per track, the process ends when the track ends.

But I've found that mplayer does send an EOF signal at a higher verbosity setting. Launching mplayer with mplayer -msglevel all=1:statusline=5:global=6 ("global=6" is the important part) generates "EOF code: 1" when it reaches end of file. The codes apparently mean different things, although I couldn't find any documentation on them, so simply listening for lines starting with "EOF code:" should be sufficient.

Assuming gmusicbrowser can detect that, a single mplayer process should be started with "-idle" flag, and files fed to it by issuing: loadfile "/path/to/file.mp3"

Better yet, in order to take advantage of mplayer2's "--gapless-audio" option, gmusicbrowser should also inform it of the next item in the playlist (probably when the current one starts playing) by also sending loadfile "/path/to/next_file.mp3" 1 where "1" is the "append" option as explained here.

Granted, even the --gapless-audio option is still experimental and imperfect (there's a short clicking noise at track transition on my system), but in any case this should be a vast improvement over the current kill-restart cycle. So the question is: did you just overlook the EOF code output, or is there something else preventing such implementation?

Thanks for this post bucaneer... I am now using mplayer as the backend and am quite satisfied with it

I do not use gapless but the performance of mplayer is impressive

I am getting this error after switching to mplayer2

This is without gapless enabled...  I am assuming this is the issue that squentin was referring to

I did not get this error with regular mplayer

No, this is unrelated. Try copying the input.conf file from /etc/mplayer to ~/.mplayer:
cp /etc/mplayer/input.conf ~/.mplayer/input.conf

^ Aye, that solved it...


#5 February 21, 2013, 22:42:48 Last Edit: February 21, 2013, 22:46:17 by bucaneer
Speaking of mplayer improvements, another small addition would be equalizer support - mplayer has equalizer as one of its audio filters, and it quite nearly matches up with the frequency bands already presented in the equalizer GUI for gstreamer. From the manual page:

10 octave band graphic equalizer, implemented using 10 IIR band pass filters. This means that it works regardless of what type of audio is being played back. The center frequencies for the 10 bands are:
No. frequency
0 31.25 Hz
1 62.50 Hz
2 125.00 Hz
3 250.00 Hz
4 500.00 Hz
5 1.00 kHz
6 2.00 kHz
7 4.00 kHz
8 8.00 kHz
9 16.00 kHz

If the sample rate of the sound being played is lower than the center frequency for a frequency band, then that band will be disabled. A known bug with this filter is that the characteristics for the uppermost band are not completely symmetric if the sample rate is close to the center frequency of that band. This problem can be worked around by upsampling the sound using the resample filter before it reaches this filter.


floating point numbers representing the gain in dB for each frequency band (-12-12)


mplayer -af equalizer=11:11:10:5:0:-12:0:5:12:12 media.avi

Would amplify the sound in the upper and lower frequency region while canceling it almost completely around 1kHz.

With an idle slave, it would be enabled by passing (for example) af_add equalizer=0:0:0:0:0:0:0:0:0:0 and changes to the configuration applied with af_cmdline equalizer 11:11:10:5:0:-12:0:5:12:12 (note the lack of "=" sign there). The changes are even applied immediately during playback, which is nice.

About using "-msglevel all=1:statusline=5:global=6" to get the EOF, thanks, I knew about -msglevel, but didn't think about using it in slave mode. It might work, I will try, but I'm not sure when (right now I'm busy updating the layout doc for the upcoming release).

About the equalizer, it's more or less planned. In fact I don't remember why I haven't already added it, maybe because I can't change it during the song without using the slave mode, or maybe I was worried about the frequencies of the equalizer being different in the gstreamer equalizer. Anyway, I'll probably do it with the slave mode.

Thanks for the response, I'll be looking forward to the updates.