Configuration of the PulseAudio ALSA plugin
Can anybody give an example where to use the pcm.pulse setting? --BertiBoeller 12:33, 17 October 2009 (EDT)
PulseAudio/Configuration was initially created to discuss PA configuration; then its goal was changed to be a replacement for this whole article; then it was abandoned. Currently it's marked for merge in PulseAudio#Configuration: is there anything worth being merged from there? -- Kynikos (talk) 04:44, 30 November 2014 (UTC)
- It seems to focus more on generic explanation/configuration, where the main article is mostly about troubleshooting (considering the size of that section, you'd consider moving it to PulseAudio/Troubleshooting ...) -- Alad (talk) 10:40, 30 November 2014 (UTC)
- How much sense would it make to actually merge PulseAudio/Configuration#Easy_configuration and PulseAudio/Configuration#Advanced_configuration and then simply redirect PulseAudio/Configuration to PulseAudio#Configuration?
- I'd agree with moving Troubleshooting to PulseAudio/Troubleshooting.
- -- Kynikos (talk) 12:01, 2 December 2014 (UTC)
Restore package list
- I'm not sure what the right policy is for this (hence my query in my edit summary) but I would just point out that the archive does stretch back to 2002 so I don't think it's unsafe to link to that material. -- Chazza (talk) 16:34, 1 August 2015 (UTC)
- Alternatively creating a pulseaudio-modules group should be equally simple for the packager, more comprehensible to the user and most naturally referenceable from the wiki. -- Lahwaacz (talk) 19:14, 1 August 2015 (UTC)
I get this error with
module-dbus-protocol is to be loaded:
W: [pulseaudio] module-dbus-protocol.c: module-dbus-protocol is currently unsupported, and can sometimes cause PulseAudio crashes. W: [pulseaudio] module-dbus-protocol.c: The most popular use cases for module-dbus-protocol are related to changing equalizer settings and LADSPA plugin parameters at runtime. W: [pulseaudio] module-dbus-protocol.c: If you don't use such functionality, it's possible that you don't actually need this module. W: [pulseaudio] server-lookup.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.BadAddress: In D-Bus address, percent character was followed by characters other than hex digits W: [pulseaudio] main.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.BadAddress: In D-Bus address, percent character was followed by characters other than hex digits
This is needed for PulseAudio#Equalizer.
Currently, the PulseAudio#Running section has the following.
- "Since version 6.0, PulseAudio relies on autospawn/socket activation. To use socket activation, enable
pulseaudio.socketfor the systemd/User instance. Alternatively, set
~/.pulse/client.confin order to use autospawn activation."
The linked upstream documentation directly advises against enabling pulseaudio.socket.
- "PulseAudio now supports systemd's socket activation. There's support only for unix sockets, though; support for TCP sockets will come later. PulseAudio ships with a ready-made socket file for starting the user instance, but it's not generally advisable to enable it, because doing so will likely prevent PulseAudio from accessing the D-Bus session bus, crippling some features that depend on the session bus. It's expected that in the future, systems that use systemd will replace the session bus with a user bus, at which point the socket activation support in PulseAudio will become usable more widely."
autospawn=yes is the default in
Finally, taking the default
autospawn=yes into consideration, Pulseaudio's autospawn works out-of-the-box. I would like to propose the following replacement.
- "Pulseaudio relies on autospawn for socket activation. This is enabled by default in
This would effectively be a removal of .
- +1 from me. The proposed sentence however implies a relation between socket activation and autospawn - former is a systemd feature, latter uses libpulse:
- "Autospawning" means that when a PulseAudio client tries to connect to the server, but the server isn't running, the server gets automatically started. The feature is part of libpulse, and it's completely transparent to applications, that is, applications don't have to explicitly add support for autospawning, autospawning is done automatically as part of the connection process of any PulseAudio application. 
- -- Alad (talk) 09:52, 7 September 2015 (UTC)
- If you rely on autospawn, systemd user services (such as
mpd.service, see Music_Player_Daemon#Autostart_with_systemd) may invoke the autospawn of PulseAudio, which is than made part of the
mpd.serviceat runtime. This is definitely not the desired behaviour, e.g. when you later start different player and stop the entire
mpd.service, PulseAudio is taken down as well, causing at least short interruption in the sound. We can either take upstream's recommendation and face immediate problems, or wait until the D-Bus thing is implemented properly and rely on the facts that Archers are able to set up D-Bus correctly (of course the section should be linked from PulseAudio#Running).
- As for the PulseAudio & D-Bus thing, do you have an answer to #DBus module? Is it specific to the case when both PulseAudio and DBus are managed as systemd user services, or a general problem?
- -- Lahwaacz (talk) 10:44, 7 September 2015 (UTC)
- If you rely on autospawn, systemd user services (such as
- I am having trouble reproducing the issue you described. It seems that it might be specific to users running dbus as a systemd service. Without configuring set up D-Bus correctly, no Pulseaudio process is spawned at boot. In my test case, I launched mpv. A Pulseaudio process is spawned, but as a subprocess of systemd, and not mpv. Furthermore, after mpv is closed, the Pulseaudio process persists. There is no issue performing handoffs between applications, and not audio artefacts.
- This may be different for users who are running dbus as a systemd service, but that should be clearly noted, and I do not see a reason to diverge from upstream and require user configuration that is not necessary. I would be happy leaving the page as is, but adding a section beforehand explaining that it is for a subset of users with a specific configuration.
- Pid1 (talk) 15:01, 7 September 2015 (UTC)