I've been using MPD as the player in my system for a few months now and I am very happy with it. There is one very odd quirk that I have not been able to overcome that occurs when I first use it after boot up - it doesn't seem to implement my audio output.
I have a single MPD audio output configured. That part of my config file looks like this:
The above forces MPD to resample audio to 16/48 format, and then passes it to an ALSA device (it's an ALSA loopback).
At first bootup, the MPD service starts up and becomes active. Since I installed MPD I have had to stop the service (and I also do "mpd --kill" for good measure) and then start it again by typing mpd at the command prpompt while logged under my username (not root). After that everything works as I expect it should, specifically it resamples the audio just like my configuration states it should.
If I do not stop/kill and restart mpd the audio still makes it to the intended device (it's also set as default in my .alsarc) but is not resampled. Since I often just cue up a CD track for testing purposes I immediately notice that the sample rate is wrong, and I can test for this and discover it using other applications that are getting the audio out of the loopback. The problem is 100% reproducible and is a problem specific to MPD (e.g. not ALSA, the other applications, etc.).
Today I tried a few different things, actually many different things. But the main one was editing the file "/etc/default/mpd". It looks like this:
Supposedly, according to this web page, you can prevent the service from starting automatically either by adding the line "START_MPD=false" as shown or you can type
I tried both of these methods, assuming I could just start it myself, or let the player force it to start when the player is opened. But this didn't work. In either case, the audio would not be resampled following the audio output in my mpd.conf file.
This is really a minor annoyance for me, but I would prefer that the service starts up and actually does what I tell it to do! Not sure why this is happening. In MPD's default config there is an ALSA output described without a card or device listed, which I believe causes MPD to use the default device. That just happens to be the same device that I have set up in my .alsarc file and this is why I still get audio but it is not resampled.
Is MPD not able to switch over to the output described in my mpd.conf file? Any ideas on how to get it to do that so I no longer need to manually stop and restart the service on bootup?
I have a single MPD audio output configured. That part of my config file looks like this:
Code:
audio_output {
type "alsa"
name "ALSA Output"
device "hw:0,0" # ALSA output used
format "48000:16:2" # audio specifier string; sample_rate:data_format:num_channels
auto_resample "no" # disable alsa resampling
auto_channels "no" # disable alsa from changing the number of channels
auto_format "no" # disable alsa format conversions
mixer_type "software" # optional
always_on "no" # do not try to keep the output connected at all times
}
samplerate_converter "0" #Best Quality Sinc InterpolatorThe above forces MPD to resample audio to 16/48 format, and then passes it to an ALSA device (it's an ALSA loopback).
At first bootup, the MPD service starts up and becomes active. Since I installed MPD I have had to stop the service (and I also do "mpd --kill" for good measure) and then start it again by typing mpd at the command prpompt while logged under my username (not root). After that everything works as I expect it should, specifically it resamples the audio just like my configuration states it should.
If I do not stop/kill and restart mpd the audio still makes it to the intended device (it's also set as default in my .alsarc) but is not resampled. Since I often just cue up a CD track for testing purposes I immediately notice that the sample rate is wrong, and I can test for this and discover it using other applications that are getting the audio out of the loopback. The problem is 100% reproducible and is a problem specific to MPD (e.g. not ALSA, the other applications, etc.).
Today I tried a few different things, actually many different things. But the main one was editing the file "/etc/default/mpd". It looks like this:
Code:
## Defaults for the MPD init script, sourced by /etc/init.d/mpd on Debian
## systems. Uncomment (remove the leading '#') and change values as needed.
## If you don't want MPD to be started as a system service (for example, if
## you want to run it from a regular user account), disable it using the
## command 'update-rc.d mpd disable' (or 'systemctl disable mpd' for systemd).
START_MPD=false
## The configuration file location for mpd:
MPDCONF=/home/charlie/.mpd/mpd.conf
Code:
sudo update-rc.d mpd disableThis is really a minor annoyance for me, but I would prefer that the service starts up and actually does what I tell it to do! Not sure why this is happening. In MPD's default config there is an ALSA output described without a card or device listed, which I believe causes MPD to use the default device. That just happens to be the same device that I have set up in my .alsarc file and this is why I still get audio but it is not resampled.
Is MPD not able to switch over to the output described in my mpd.conf file? Any ideas on how to get it to do that so I no longer need to manually stop and restart the service on bootup?
Last edited:
That example you provided uses Ubuntu "Jaunty". That's more than a little old (2009). Certainly, I recall the "update-rc.d" erm.... method was deprecated. These days we're supposed to use "systemd", I think....
A more up to date description of mpd configuration can be found here.
https://wiki.archlinux.org/index.php/Music_Player_Daemon
When the problem occurs, have you tried "ps -A | grep mpd". It occurs to me that it's possible there are multiple "startss" for mpd in the system somewhere. (If that's even possible).
J.
A more up to date description of mpd configuration can be found here.
https://wiki.archlinux.org/index.php/Music_Player_Daemon
When the problem occurs, have you tried "ps -A | grep mpd". It occurs to me that it's possible there are multiple "startss" for mpd in the system somewhere. (If that's even possible).
J.
I think this is a problem with MPD itself, not with the system or its service control. Or I have not configured something correctly.
I think what is happening is that when the MPD service is started it is reading the default MPD config file. That's not the one I am editing or using. I have a custom version in a subdir of my home directory. I followed some setup instructions for this in the beginning and, apart from the odd startup issue of this thread, everything works perfectly.
If I can't figure out what is going on I may just copy my user config over the default config (after backing it up) and see if that solves the problem.
I think it's MPD's behaviour depending on how it is started.
Starting it as a system service it will read from /etc/mpd.conf . Whereas, if started in user-space, it reads from ~/.config/mpd.conf or ~/.mpd/mpd.conf.
It seems you're not alone in this problem...
https://www.reddit.com/r/linuxquestions/comments/348c0l/mpd_autostart_with_systemd/
J.
Starting it as a system service it will read from /etc/mpd.conf . Whereas, if started in user-space, it reads from ~/.config/mpd.conf or ~/.mpd/mpd.conf.
It seems you're not alone in this problem...
https://www.reddit.com/r/linuxquestions/comments/348c0l/mpd_autostart_with_systemd/
J.
I won't provide a solution, but I have a similar understanding that it may be related to the way mpd is started. My set-up works perfectly when started from my account, and not when started as a daemon. Even if I have configured everything (as far I understand) for the mpd dedicated user and its group (as defined in the /etc/mpd.conf)... To workout further later.
JMF
JMF
Second note states mpd uses /etc/mpd.conf if started as a system service.
https://wiki.archlinux.org/index.php/Music_Player_Daemon#Autostart_with_systemd
J.
https://wiki.archlinux.org/index.php/Music_Player_Daemon#Autostart_with_systemd
J.
From my experience there are two different behaviors of mpd depending on how it is started.
1. The computer powers up and the mpd service (-no-daemon) auto starts. MPD uses the configuration file /etc/mpd.conf
2. If you log in as a user, stop the mpd service, and then type mpd at the command prompt mpd uses the configuration file ~/.mpd/mpd.conf
I have exclusively been editing the user configuration file ~/.mpd/mpd.conf. I didn't even know that the one in /etc existed! But I want the same behavior for both instances, and I want all the log info and other files to be in my user directory.
My solution to this was to move /etc/mpd.conf to /etc/mpd.conf.bak, then move ~/.mpd/mpd.conf to /etc/mpd.conf and finally to create a symbolic link to /etc/mpd.conf at ~/.mpd/mpd.conf. That was there is really only one file but it can be accessed, and edited, from both locations.
Now, no matter how I start mpd (as a service or as a user) the same config is used and the behavior is the same.
1. The computer powers up and the mpd service (-no-daemon) auto starts. MPD uses the configuration file /etc/mpd.conf
2. If you log in as a user, stop the mpd service, and then type mpd at the command prompt mpd uses the configuration file ~/.mpd/mpd.conf
I have exclusively been editing the user configuration file ~/.mpd/mpd.conf. I didn't even know that the one in /etc existed! But I want the same behavior for both instances, and I want all the log info and other files to be in my user directory.
My solution to this was to move /etc/mpd.conf to /etc/mpd.conf.bak, then move ~/.mpd/mpd.conf to /etc/mpd.conf and finally to create a symbolic link to /etc/mpd.conf at ~/.mpd/mpd.conf. That was there is really only one file but it can be accessed, and edited, from both locations.
Now, no matter how I start mpd (as a service or as a user) the same config is used and the behavior is the same.
Yes, I think that is fine, and probably much simpler than what I did!
I'm not exactly sure what happens if you try to run mpd as a user and not as the service, but if you never do that there is probably nothing to worry about.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.