Pulseaudio and MPD Coexisting has me baffled [Solved]

ewaller · 2011-01-29 07:18:45

What with the recent changes in KDE, I find myself being nudged towards accepting Pulseaudio on my system.

I have scoured the Wiki and these forums. There is significant documentation on these, but some of it I know is dated, I suspect most of it is.

Here is the issue as I understand it:

Pulseaudio is to be run on a per user basis (upstream practically insists on it, except for extraordinary cases)
MPD (on Arch) wants to run as the user mpd, started by the initscripts.

In the default configuration, MPD grabs the Alsa audio subsystem and won't share nicely with pulsesaudio which is started after a user logs in.

Telling MPD to not grab Alsa, but rather use the pulse driver does not work -- it complains that it cannot open the audio device. I do not know if that is because the pulse system had not been instantiated prior to MPD starting, or because Pulseaudio, owned by the user, wont share with that guy called mpd.

Trying to start mpd as a user (after creating a ~/.mpdconf file) fails with not being able to bind localhost.

Lastly, I don't think I have a problem with access to mpd using a tool like mpc, because it shows the current state of mpd (the song title, metadata, the mpd state, and the fact it cannot open the audio device). Regardless, the Wiki talks about a few groups -- pulse, pulse-rt, and pulse-access. Those groups do not exist on my system -- are they depreciated, did I miss the memo?

I feel like I am chasing my tail in circles here. What are the ideal forms for Pulseaudio and MPD in the land of Arch?

Thanks.

Last edited by ewaller (2011-01-29 18:06:10)

ngoonee · 2011-01-29 09:41:09

I'm running mpd as my own user, what's the problem? Its been a long time and I can't remember exactly what I did, but it was basically just from the Arch wiki (maybe a bit from the mpd wiki, but I don't like their wikia).

Don't use the pulse/pulse-rt/pulse-access groups, those are deprecated in favour of using ck instead (if you're using KDE you already have it working).

Rasi · 2011-01-29 11:11:00

ewaller wrote:

MPD (on Arch) wants to run as the user mpd, started by the initscripts.

there is nothing wrong with this, but i highly disagree with archs implementation. It has no real advantage and only confuses the users.
- Run mpd as your own user (as daemon: put user "YOURUSER" in mpd.conf, or simply start mpd binary as user (in that case comment out the user option in mpd.conf)
- create some mpd specific folder (e.g. ~/.mpd and ~/.mpd/playlists)

still nothing wrong running mpd as another user, but i just dont see the gain.

Last edited by Rasi (2011-01-29 11:11:58)

ewaller · 2011-01-29 16:39:28

Thanks guys. Good Morning (GMT-8).

I tend towards the idea that mpd should be run for by the user rather than as a system service. I had had my system set up as a Gentoo machine running in just that way. As a matter of fact, my ~ already has the .mpd files, the music directory, playlist directories, and log files all set up and ready to go. I did audit them for any quirks of Arch vs Gentoo.

The problem I encounter is when, as a user, logged in, with Pulseaudio started, I run mpd -- It complains that it cannot bind localhost.

Rasi wrote:

- Run mpd as your own user (as daemon: put user "YOURUSER" in mpd.conf, or simply start mpd binary as user (in that case comment out the user option in mpd.conf)

Interesting idea. It violates somewhat my sense of order (it is a bit hackish), but it implementing that will certainly give me some good indication of how to proceed.

What I take away from this is (1) pulseaudio and mpd running as a user is known to work, (2) as I suspected, pulse groups are depreciated, and (3) my head is not up and locked.

Thanks again. I'll get back with a little later with my progress.

ewaller · 2011-01-29 18:05:27

Found it ~/.mpdconf was trying to instantiate a socket in /var. So much for meaningful error messages

I can now start mpd as a user and play through pulseaudio.

Thanks again

Rasi · 2011-01-29 21:43:33

ewaller wrote:

Found it ~/.mpdconf was trying to instantiate a socket in /var. So much for meaningful error messages
Thanks again

mpd --verbose --stdout --nodaemon

ngoonee · 2011-01-29 23:05:13

ewaller wrote:

Found it ~/.mpdconf was trying to instantiate a socket in /var. So much for meaningful error messages
I can now start mpd as a user and play through pulseaudio.
Thanks again

Wasn't that mentioned in the wiki? I'm pretty sure the directions there instruct you to modify a certain set of values in mpd.conf...

ewaller · 2011-01-29 23:45:56

ngoonee wrote:

Wasn't that mentioned in the wiki? I'm pretty sure the directions there instruct you to modify a certain set of values in mpd.conf...

Well, yes; and no.

My .mpdconf looked like this:

...
# This setting sets the address for the daemon to listen on. Careful attention
# should be paid if this is assigned to anything other then the default, any.
# This setting can deny access to control of the daemon.
#
# For network
#bind_to_address                "localhost"
#
# And for Unix Socket
bind_to_address                "/var/lib/mpd/socket"
...

That is an artifact of the Gentoo setup which had worked. Had I used the Arch configuration as a baseline, I would not have stepped on myself. The things in the wiki addressed where to put the logs, database, pid, etc... As such, I would have to say the wiki is correct as it stands (with regards to the user configuration file)

Rasi wrote:

mpd --verbose --stdout --nodaemon

Yeah, I did not do that _because_ I believed MPD when it said it could not bind localhost. It wasn't. It was trying to create the socket. I feel it led me down the primrose path. Not the first time it has happened, and I am sure it won't be the last.

I think the issue that may need some more attention is that if one installs both pulseaudio and mpd, the default configurations won't work. I assert that one cannot start mpd from the initscripts configured to run as the user mpd and then start pulseaudio after another user logs in, and have it all work. Does this warrant an update to the wiki, or perhaps a bugzilla report on mpd ? (I must confess, I just looked there -- I had forgotten to look before; I'm glad there wasn't a report on this)

Last edited by ewaller (2011-01-29 23:46:32)

ngoonee · 2011-01-30 05:21:44

ewaller wrote:

I think the issue that may need some more attention is that if one installs both pulseaudio and mpd, the default configurations won't work. I assert that one cannot start mpd from the initscripts configured to run as the user mpd and then start pulseaudio after another user logs in, and have it all work. Does this warrant an update to the wiki, or perhaps a bugzilla report on mpd ? (I must confess, I just looked there -- I had forgotten to look before; I'm glad there wasn't a report on this)

Sorry, 'just works' won't happen. There's too many different use-cases. mpd cannot (and should not) be auto-configured to support pulseaudio or to run as user because some (many) don't want to use it that way.

And putting a note on the wiki is possible of course, but considering how long the mpd article already is I think its fine.

Arch Linux

#1 2011-01-29 07:18:45

Pulseaudio and MPD Coexisting has me baffled [Solved]

#2 2011-01-29 09:41:09

Re: Pulseaudio and MPD Coexisting has me baffled [Solved]

#3 2011-01-29 11:11:00

Re: Pulseaudio and MPD Coexisting has me baffled [Solved]

#4 2011-01-29 16:39:28

Re: Pulseaudio and MPD Coexisting has me baffled [Solved]

#5 2011-01-29 18:05:27

Re: Pulseaudio and MPD Coexisting has me baffled [Solved]

#6 2011-01-29 21:43:33

Re: Pulseaudio and MPD Coexisting has me baffled [Solved]

#7 2011-01-29 23:05:13

Re: Pulseaudio and MPD Coexisting has me baffled [Solved]

#8 2011-01-29 23:45:56

Re: Pulseaudio and MPD Coexisting has me baffled [Solved]

#9 2011-01-30 05:21:44

Re: Pulseaudio and MPD Coexisting has me baffled [Solved]

Board footer