On Tue, Dec 21, 2010 at 5:11 PM, CarstenBreuer <carstenbreuer...@textwork.de> wrote: > Hi Sean, > > > thank you very much for your explanations > about PulseAudio. I was able to play audio > with MPD over the SPDIF output of the synergy > soundcard, but i have to configure it from > the GUI. > > The following questions are left: > > 1. How can i list and then select the profiles > for a card from the command line?
I'll be working under the assumption that module-udev-detect or module-detect is loaded into your PA daemon. This is the default with recent versions of PA (definitely anything from 2009 - 2010). First of all, use `pactl list' to verify that each of your distinct hardware soundcards are listed. Each card will be listed as an entry beginning with "Card #N", where N starts from 0. If all your cards are listed, then rejoice; PA's detection logic is working properly, and you can move on. If all the cards aren't listed, this is most likely a driver bug in ALSA, but because of the way this negatively affects usability with PA, it might be something that the PA maintainers could take a look at. But if you want them to help you, you'll probably need to run the latest stable PA (or PA from git) and use module-udev-detect, since that is the only really well-supported detection mechanism for now. Alternatively, you can manually load one or more "module-alsa-sink" modules in /etc/pulse/default.pa, specifying the appropriate ALSA device string. But this is a significant departure from the convenience of a 100% properly-working module-udev-detect, so IMHO you should work that path as much as you can. OK, now moving on with the assumption that your cards are listed in pactl list: What you need to do is get the "Name" field out of the output. For example, on my hardware, Card #0 lists immediately underneath it the line: "alsa_card.pci-0000_02_00.0" This is the name that should go, verbatim, in the `sink' property of the pulse audio_output in mpd.conf. But I think you already grok this; I'm just reviewing :) Moving on to profiles. Unfortunately, it's not documented in `man pactl', but if you run: `pactl --help' you will see: "pactl [options] set-card-profile CARD PROFILE" Just to document this briefly, because the manpage falls down: The "CARD" parameter is *either* the sink name, e.g. "alsa_card.pci-0000_02_00.0", *or* the card index, e.g. "0". The "PROFILE" parameter can be extracted, again, from our handy-dandy `pactl list'. Within the listing for each card will be a sequence of Profiles. An example of a Profile line is the following: "output:analog-mono+input:analog-stereo: Analog Mono Output + Analog Stereo Input (sinks: 1, sources: 1, priority. 160)" The part of this string that represents the profile name is, in this example, "output:analog-mono+input:analog-stereo". That is, everything up until (but not including) the last colon and before the first space. Hopefully you aren't planning to try and script that, or else, get ready for regular expressions or using a string library with indexOf ;) The good news is that the profile will be remembered between PA startups, because PA keeps its own database of these kinds of settings. I must note however that the settings *are* per-user. So, a fully constructed `pactl set-card-profile' line would look something like this: pactl set-card-profile alsa_card.pci-0000_02_00.0 output:analog-mono+input:analog-stereo You can confirm this changing with gnome-volume-control-applet; click the Hardware tab of the GUI, then run your pactl s-c-p, and it should update in the GUI within a very short time. Once you are satisfied with this behavior, there's no need to explicitly save your settings; next time PA starts, the same profile will be used again. Finally, to determine which Profile is currently active, note again the last line of the output for each Card stanza in pactl. It ends with a line saying "Active Profile:" followed by the name of -- you guessed it -- the active profile. > 2. Where is the gnome stuff, that starts a pulseaudio > server when a user logged in and stops it after > he/she logged out? This isn't actually GNOME-specific. This is actually based on something called ConsoleKit. ConsoleKit is independent from PulseAudio; it is a fairly new part of a standard Linux system's middleware infrastructure. It was released just a couple years ago, debuting in Fedora and making its way through Ubuntu, Debian, SUSE, etc. PulseAudio has ConsoleKit integration, meaning that it asks ConsoleKit to tell PA when a desktop session is logged in, and when is it terminated. This functionality is not built-in; it is part of a module. Quoting from the standard upstream default.pa: "### If autoexit on idle is enabled we want to make sure we only quit ### when no local session needs us anymore. load-module module-console-kit" You can learn more about ConsoleKit here, http://www.freedesktop.org/wiki/Software/ConsoleKit or more about PA's usage thereof here: http://pulseaudio.org/wiki/Modules#module-console-kit (note: if you learn more about this module, you should document your learning experience by editing the PA wiki to add more information for future querents; the description so far is just a stub). > 2. "pactl list" doesn't work "access denied" if i start > pulseaudio systemwide (--system). > What's the best way to do ir? It's "3.", and I think you are getting access denied because your user isn't in the pulse-access group. `pactl' is just another ordinary PulseAudio client, so you should also be getting access denied when you try to play sound as that user. The system-wide daemon mode is strongly discouraged, for many reasons. There are security, performance, and system integration issues with systemwide that have not been addressed. The PA maintainers recognize that there are some corner-case valid usages of systemwide, but it is recommended that you start PA as a regular user if at all possible. To sum it up, PA is not really designed to work well in system-wide mode, and if you insist on doing it anyway, you have to be aware of all the disadvantages, and learn how to deal with them. But IMHO it is far easier to just run PA as a user. It's not worth sacrificing the performance of shared memory as a transport; TCP has too much overhead for many applications. See http://pulseaudio.org/wiki/WhatIsWrongWithSystemMode for details. Based on my understanding of your particular setup, my suggestion would be: ***One-Time Setup Tasks*** 1. Set up a distro-specific console login script, or init.d entry, or whatever, to start PulseAudio as some user (I'll call this user "mpd" for this discussion). PA needs to start up at a point in time that is distinctly before the time when you start the mpd daemon(s), so that mpd doesn't start up before PA. If you use an init.d script, which runs as root, then you can use the `su' program to start PA as the "mpd" user without typing a password. The `--start' parameter to PA may prove useful. 2. Modify /etc/pulse/default.pa: you probably don't want to load module-console-kit. I could be wrong though; there may be a way to use ConsoleKit without logging into X! The fact is I just don't know enough about it to give you sound advice. I do know, however, that if you disable module-console-kit, then you can manually control the lifetime of PA using your own hand-rolled scripts, and ConsoleKit won't interfere. 3. Play with `pactl list', `pactl set-card-profile', and mpd.conf, until you get each mpd daemon outputting to the desired soundcard, and each soundcard has the desired profile. Once you have these things set up, you won't have to change them at all unless you start swapping out soundcards in your system. Normally, PA handles soundcard swapping (such as hot-plugging USB headsets) extremely well, but since you have to kind of hard-code which card is used for each mpd, your configuration is necessarily a bit more brittle than most PA setups. If you do frequently change soundcards, this may become an ongoing maintenance task. 4. If other users on the system want to play sound through your PA daemon, you may have to enable module-native-protocol-tcp, or change the permissions of the UNIX socket, depending on your goals. But in principle, it should be possible to run PA as the "mpd" user, and have user "foo" login to GNOME and play audio through Rhythmbox (or whatever) to the "mpd" user's PA daemon. Of course, it would use the default sink unless otherwise specified. Default settings for the server and sink can be explicitly specified for *all* PA clients (unless overridden by the client) in /etc/pulse/client.conf, which also has a manpage, `man pulse-client.conf'. ***Ongoing Maintenance Tasks*** 1. Make all the music files you want to play, readable (and directories executable) by the mpd user. ***Every Boot Tasks*** 1. Start your mpd daemon(s) all under the same "mpd" user. And just to clarify something I said earlier: the `pulse-access' group only comes into play if you are using the System-Wide Daemon mode, which I really think you should avoid. One last thing: Since this email is almost completely PA-specific and very little to do with mpd, I would suggest that you mail pulseaudio-disc...@mail.0pointer.de if you have any further PA-specific questions. There's also #pulseaudio on freenode IRC. I'm not a PA developer; I've just been using it for a number of years. But the developers surely know this stuff better and could probably give you more sound advice. The ML and IRC channel are both reasonably active. HTH, -Sean > > Thanks a lot for your support :-). > > > Best Regards, > > > > Carsten > > > > ------------------------------------------------------------------------------ Forrester recently released a report on the Return on Investment (ROI) of Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even within 7 months. Over 3 million businesses have gone Google with Google Apps: an online email calendar, and document program that's accessible from your browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
