mpd is not configured to use pulseaudio

As of Karmic at least, it does have this option, but commented out. Since Ubuntu uses Pulseaudio by default, so should MPD.

mpd -> pulse does not work on karmic!

Well it should! (Not necessarily in karmic, but in a future release.)

The problem with using the mpd output in the system mpd daemon is that it will not have permission to speak to your user's pulseaudio daemon.

I have found the easiest way around this is to make a local (to your user) config file for mpd, updating relevant parts of it to point to /home/<you>/.mpd/* instead of /var/lib/mpd/* and having it launch as you on login (I haven't tried launching on startup, but that might work just as well).

Alternatively it is possible to configure pulseaudio to run as a system wide daemon, in which case users (including mpd) need to be in the pulse group (or it might be pulse-access, sorry I can't quite remember), but I have found this can cause other issues with pulseaudio, and isn't recommended by the pulseaudio devs.

For these reasons I don't think configuring mpd to use pulseaudo by default is a good idea, but perhaps someone knows of a better way to set things up, in which case I'd like to know about it ⢁).

In Lucid Lynx (at least with me), mpd plays music through pulseaudio correctly, but it appropriates of pulseaudio's output. So, while having mpd playing music, other apps cannot use pulseaudio output 'cause it's owned by mpd. And this was my workaround:

Adding mpd user to pulseaudio groups didn't work. So, the simplest way was replacing the mpd user from the /etc/mpd.conf file by my user (rcart). After restarting mpd, it will claim 'cause the user has not permissions on the /var/run/mpd/pid file, and this is solved by changing the pid file owner to the user (in this case rcart).

Those lines look like this:

/etc/mpd.conf:
       user "rcart"

/var/run/mpd/pid permissions:
       -rw-r--r-- 1 rcart root 4 2010-07-30 16:30 /var/run/mpd/pid

Hope that works for those who have the same problem =)

On 31 July 2010 03:11, Rcart <email address hidden> wrote:
> In Lucid Lynx (at least with me), mpd plays music through pulseaudio
> correctly, but it appropriates of pulseaudio's output. So, while having
> mpd playing music, other apps cannot use pulseaudio output 'cause it's
> owned by mpd. And this was my workaround:
>
> Adding mpd user to pulseaudio groups didn't work. So, the simplest way
> was replacing the mpd user from the /etc/mpd.conf file by my user
> (rcart). After restarting mpd, it will claim 'cause the user has not
> permissions on the /var/run/mpd/pid file, and this is solved by changing
> the pid file owner to the user (in this case rcart).
>
> Those lines look like this:
>
> /etc/mpd.conf:
>       user                            "rcart"
>
> /var/run/mpd/pid permissions:
>       -rw-r--r-- 1 rcart root 4 2010-07-30 16:30 /var/run/mpd/pid
>
> Hope that works for those who have the same problem =)

While your method does work for the most part it can sometimes still
cause some issues with applications accessing pulseaudio.
The patch to mpd in Ubuntu that allows that to work is one I would
like to see dropped as running the mpd system daemon as a normal user
is not supported at all by mpd upstream.

If you want to run mpd as yourself the method I mentioned above is
much neater in my opinion. There are more detailed instructions for
how to do that on the gmpc wiki:
http://gmpc.wikia.com/wiki/MPD_INSTALL_USER_SERVICE_UBUNTU

--
Matt Wheeler
<email address hidden>

Natty's mpd is still not configured to use pulseaudio by default, which seems silly given that PulseAudio has been the default sound system for several releases now...

On 13 April 2011 16:46, Reuben Thomas <email address hidden> wrote:
> Natty's mpd is still not configured to use pulseaudio by default, which
> seems silly given that PulseAudio has been the default sound system for
> several releases now...

As far as I'm aware nothing I said in my previous comments has changed
yet, either in pulseaudio or in mpd, so I still don't think it makes
sense to configure MPD for PA by default.

It's not ideal that people who want to use mpd need to do some
fiddling to get it to work, but this isn't an easy problem to solve
properly.

--
Matt Wheeler
<email address hidden>

On 14 April 2011 02:46, Matt Wheeler <email address hidden> wrote:
> On 13 April 2011 16:46, Reuben Thomas <email address hidden> wrote:
>> Natty's mpd is still not configured to use pulseaudio by default, which
>> seems silly given that PulseAudio has been the default sound system for
>> several releases now...
>
> As far as I'm aware nothing I said in my previous comments has changed
> yet, either in pulseaudio or in mpd, so I still don't think it makes
> sense to configure MPD for PA by default.

There's no conflict here. I'm using a per-user mpd, and there's
nothing to stop the system configuration in /etc/mpd.conf contain an
uncommented audio_output stanza to use ALSA or whatever. If mpd is
built to default to PulseAudio, then per-user configurations don't
have to know this, and the system configuration can still default to
ALSA (or whatever), with a note explaining why.

--
http://rrt.sc3d.org

Confirmed for Ubuntu 11.04 x86_64. In my case I need to add both alsa and pulseaudio outputs for making it work.

In addition, I can confirm #5 comment regarding mpd exclusively appropriates the audio device.

On 14 April 2011 12:15, Reuben Thomas <email address hidden> wrote:
> There's no conflict here. I'm using a per-user mpd, and there's
> nothing to stop the system configuration in /etc/mpd.conf contain an
> uncommented audio_output stanza to use ALSA or whatever. If mpd is
> built to default to PulseAudio, then per-user configurations don't
> have to know this, and the system configuration can still default to
> ALSA (or whatever), with a note explaining why.

I don't believe that mpd has such "build default" settings (and I
don't really see a pressing need for it to start having them).

Potentially what you want could be achieved by setting
MPDCONF=/etc/mpd.conf-system or some such (see /etc/default/mpd), and
using /etc/mpd.conf for normal user instances of mpd, but this assumes
that every user wants exactly the same configuration for their
individual mpd.

Perhaps issues with pulseaudio should be documented better in
mpd.conf's comments, or an alternative example .mpdconf could be
provided with the package, and mentioned in README.Debian?

--
Matt Wheeler
<email address hidden>

> I don't believe that mpd has such "build default" settings (and I
> don't really see a pressing need for it to start having them).

If you look at the source, you can see that in the absence of a sound output configuration, audio_output_detect calls ao_plugin_test_default_device for each output plugin that has a test_default_device handler.

The order in which the plugins are given is simply that in which they are listed in output_list.c. There, you can see that alsaPlugin is listed before pulse_output_plugin. Hence, on Ubuntu, ALSA is preferred to PulseAudio.

That is what I meant by a build default.

Now to be clear about what I want: what I am trying to achieve here is an mpd package which does not require user configuration to work on a default Ubuntu install (which the current system does, as a default Ubuntu install uses PulseAudio, while mpd defaults to using ALSA). mpd can be packaged in such a way that a user does not need do anything other than install it to use it; I'm just trying to get closer to that goal.

Currently, there are two ways in which mpd can be used on Ubuntu: as a system server, or per-user. Both can be made to work by default with (per-user) PulseAudio. As explained on

http://mpd.wikia.com/wiki/PulseAudio

if mpd is run in system mode, then the mpd user needs to be a member of the pulse-access group to be able to access the user's PulseAudio daemon. (You mention above that "I have found this can cause other issues with pulseaudio, and isn't recommended by the pulseaudio devs." If that is still the case, please can you explain the problems and point to the advice, as the wiki page referred to above clearly needs updating.)

On the other hand, if mpd is run in user mode, it can access PulseAudio already. Both these can be achieved by adding a PulseAudio configuration stanza to /etc/mpd.conf. Maybe it is worth considering making this the default mode of operation of mpd in any case: most users, whether on single-user or multi-user machines, are likely to want to play their own music collections, not some central collection, and running per-user mpd instances also reduces the likelihood of security problems.

> Potentially what you want could be achieved by setting
> MPDCONF=/etc/mpd.conf-system or some such (see /etc/default/mpd), and
> using /etc/mpd.conf for normal user instances of mpd, but this assumes
> that every user wants exactly the same configuration for their
> individual mpd.

In fact, the situation is better than this: mpd searches first for a per-user configuration file (actually not ~/.mpdconf as mpd(1) says, but ~/.mpd/mpd.conf), and then for /etc/mpd.conf. Thus, users who want different settings for their individual mpd have only to write a ~/.mpd/mpd.conf exactly as at present. Any user who already has a ~/.mpd/mpd.conf file will not be affected by the change I propose.

> Perhaps issues with pulseaudio should be documented better in
> mpd.conf's comments, or an alternative example .mpdconf could be
> provided with the package, and mentioned in README.Debian?

There's no need: there is no issue other than one of default configuration. We can have our cake and eat it here.

By the way, I should add that I use a Startup Applications entry to run my per-user mpd, and this works very well; mpd could easily provide such an entry as part of the package.

On 7 May 2011 01:44, Reuben Thomas <email address hidden> wrote:
> If you look at the source, you can see that in the absence of a sound
> output configuration, audio_output_detect calls
> ao_plugin_test_default_device for each output plugin that has a
> test_default_device handler.
>
> The order in which the plugins are given is simply that in which they
> are listed in output_list.c. There, you can see that alsaPlugin is
> listed before pulse_output_plugin. Hence, on Ubuntu, ALSA is preferred
> to PulseAudio.
>
> That is what I meant by a build default.

That is interesting, I haven't looked in depth at the source as I know
pretty much no C. It probably makes sense for mpd to prefer pulseaudio
to alsa on systems where it can access pulseaudio... do you know if
ao_plugin_test_default_device would attempt to use pulseaudio just
because it is installed, or is it clever enough to check it can
actually make a connection?

> Now to be clear about what I want: what I am trying to achieve here is
> an mpd package which does not require user configuration to work on a
> default Ubuntu install (which the current system does, as a default
> Ubuntu install uses PulseAudio, while mpd defaults to using ALSA). mpd
> can be packaged in such a way that a user does not need do anything
> other than install it to use it; I'm just trying to get closer to that
> goal.

That seems like a worthwhile goal :)

> Currently, there are two ways in which mpd can be used on Ubuntu: as a
> system server, or per-user. Both can be made to work by default with
> (per-user) PulseAudio. As explained on
>
> http://mpd.wikia.com/wiki/PulseAudio
>
> if mpd is run in system mode, then the mpd user needs to be a member of
> the pulse-access group to be able to access the user's PulseAudio
> daemon. (You mention above that "I have found this can cause other
> issues with pulseaudio, and isn't recommended by the pulseaudio devs."
> If that is still the case, please can you explain the problems and point
> to the advice, as the wiki page referred to above clearly needs
> updating.)

http://www.pulseaudio.org/wiki/WhatIsWrongWithSystemMode

I encountered problems with pulseaudio "stealing" audio if I tried to
use it with per-user pulseaudio when it was running as a system user,
even during the brief period when I ran the system daemon as the same
user as me. If the pulseaudio daemon starts up and plays music before
the user logs in no other applications can use the soundcard, because
it got locked by the instance of pulseaudio spawned when mpd started
up.

> On the other hand, if mpd is run in user mode, it can access PulseAudio
> already. Both these can be achieved by adding a PulseAudio configuration
> stanza to /etc/mpd.conf. Maybe it is worth considering making this the
> default mode of operation of mpd in any case: most users, whether on
> single-user or multi-user machines, are likely to want to play their own
> music collections, not some central collection, and running per-user mpd
> instances also reduces the likelihood of security problems.

I'd argue that the system-wide daemon (with appropriate symlinks to
user music dirs) provides better security from the user's point of
view, a...

I've done some more work on this. I filed a bug suggesting that mpd detect PulseAudio before ALSA, but there is a reasonable objection to this: with PulseAudio configured to auto-spawn, this can result in PulseAudio being started for a user who does not want it (on a system where pulseaudio is installed but not used by default). ALSA's own pulse-audio detection code may or may not have this problem too; I'm not sure, as I don't understand PulseAudio's quite complex API. Link to bug report:

http://musicpd.org/mantis/view.php?id=3234

Thanks for the link about not running PulseAudio in system mode; I've added a note about this to the mpd page I cited.

So it seems that the best solution is indeed to modify mpd's /etc/mpd.conf.

There is another matter, which is that ALSA is set up to use PA by default anyway on recent Ubuntu. For some reason, it doesn't work when I start mpd normally, but does work if I start it with --no-daemon. I don't yet know whether this is a bug in mpd or libasound, but I'll file a separate bug. In any case, I would argue that it's still best to fix *this* bug by a default configuration that uses PA directly, as that avoids going through an extra stage ALSA→PA→ALSA, which is just asking for yet more bugs (like the one I've just found!) and/or performance problems.

The curent mpd package ships with an XDG autostart file, which will try to start a user mpd upon logging in. This will (intentionally) fail if a system mpd is already running, as the necessary port is not free, and it will also fail if the configured paths to log and database are not writeable for the user running mpd, which means that the default /etc/mpd.conf will only work for a system mpd and actually running a user mpd requires to manually provide a ~/.mpdconf, e.g. from /usr/share/doc/mpd/examples/mpdconf.example.gz

I have no idea how to make this last bit automatic without destroying the system mpd functionality. Suggestions welcome!

This bug still needs fixing.

Since mpd is now run by default per-user, if system mpd is disabled, the fix would require a patch to mpd's source code to have it try PulseAudio before ALSA. This would have the disadvantage stated in comment #15 that it could result in PulseAudio being started for a user who doesn't want it, but I suggest that such users are relatively rare compared to those who use the default Ubuntu setup, and we can put a note in README.Debian about how to configure mpd to avoid this.

At the same time, /etc/mpd.conf should be modified to comment out explicit configuration of ALSA.

If this is acceptable to the maintainers, I'm happy to work out the (trivial) patch (or perhaps it should go to Debian if Debian uses PulseAudio by default; Florian, I guess you'll know?).