Comment 14 for bug 374059

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, assuming mpd has exploitable bugs, but I guess it swings both
ways...

> 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.

Yep this makes sense

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

And this

It's late so I might not have thought this through as well as
possible, just saying :)

--
Matt Wheeler
<email address hidden>