Difference between revisions of "Talk:PulseAudio"

From ArchWiki
Jump to: navigation, search
(Equalizer module is unsupported: new section)
(Proposed Corrections: Added a note that the article was updated for Pulseaudio 7 and Arch's new behavior (which deviates from upstream).)
Line 107: Line 107:
:::::::::::::Oh. So we'll need to decide whether to keep describing autospawn at all... [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:40, 21 September 2015 (UTC)
:::::::::::::Oh. So we'll need to decide whether to keep describing autospawn at all... [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:40, 21 September 2015 (UTC)
::::::::::::::I have updated the article to reflect the new behavior, as it deviates from upstream's defaults. I have retained a link to [http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Running/ upstream], though our behavior is quite different. Any technical or stylistic modifications are welcome. [[User:Pid1|Pid1]] ([[User talk:Pid1|talk]]) 16:35, 1 October 2015 (UTC)
== Equalizer module is unsupported ==
== Equalizer module is unsupported ==

Revision as of 16:36, 1 October 2015

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)

Abandoned draft

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)
I do agree it makes sense to merge PulseAudio/Configuration#Easy_configuration and PulseAudio/Configuration#Advanced_configuration in PulseAudio/Configuration. I made an attempt in this way. Gabx (talk) 18:24, 28 December 2014 (UTC)
I like what I see so far, more extensive configuration in the main article also allows to cut back on PulseAudio/Troubleshooting. -- Alad (talk) 23:29, 28 December 2014 (UTC)

Restore package list

Why revert the list? I think Arch News is just a temp reminder. Arch Wiki should keep all needed info.--Fengchao (talk) 09:37, 1 August 2015 (UTC)

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)
That's true, but the set of split packages can change in the future... -- Lahwaacz (talk) 18:37, 1 August 2015 (UTC)
Exactly, so at that time, the news page is out of date and only wiki page could be updated to keep up.--Fengchao (talk) 12:57, 19 August 2015 (UTC)
We should ask for a more extensive optdepends instead of maintaining this information here. -- Alad (talk) 19:03, 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)
Then before a group is created, should we restore the package list?--Fengchao (talk) 12:57, 19 August 2015 (UTC)
I don't think any action need be taken until such a time that the set of split packages changes. -- Chazza (talk) 17:14, 7 September 2015 (UTC)

DBus module

I get this error with pulseaudio-6.0-2 when 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.

-- Lahwaacz (talk) 18:58, 23 August 2015 (UTC)

To reproduce this message when PulseAudio is not running as a systemd user service, make sure that the log target is configured properly (extra-arguments defaults to --log-target=syslog):
extra-arguments = --log-target=journal
-- Lahwaacz (talk) 15:42, 7 September 2015 (UTC)
Since pulseaudio-7.0 the message is gone, closing. -- Lahwaacz (talk) 08:37, 28 September 2015 (UTC)

Proposed Corrections

Currently, the PulseAudio#Running section has the following.

"Since version 6.0, PulseAudio relies on autospawn/socket activation. To use socket activation, enable pulseaudio.socket for the systemd/User instance. Alternatively, set autospawn=yes in either /etc/pulse/client.conf or ~/.pulse/client.conf in 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."

Furthermore, autospawn=yes is the default in /etc/pulse/client.conf.

Finally, taking the default /etc/pulse/client.conf 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 /etc/pulse/client.conf."

This would effectively be a removal of [1].

Pid1 (talk) 00:42, 7 September 2015 (UTC)

+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. [2]
-- 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.service at runtime. This is dcurrently unsupportedefinitely 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)
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)
I should note that I am referring to the sound interruptions, and not #DBus module.
Pid1 (talk) 15:15, 7 September 2015 (UTC)
Have you run mpv as a systemd service? If that is the case, what was the output of systemd-cgls? -- Lahwaacz (talk) 15:20, 7 September 2015 (UTC)
That requires set up D-Bus correctly, correct? Are we assuming that every user either 1) has configured that, or 2) wants to configure that? It is not necessary for Pulseaudio. Pid1 (talk) 15:24, 7 September 2015 (UTC)
I asked if you run mpv as systemd service, because I referred to mpd started with systemd for the example which would cause trouble. If you run all applications the classical way, they end up under user-$UID.slice/session-c$NUM.scope in the systemd-cgls output and of course daemons will persist if a client exits. However, if a systemd service (such as mpd.service) requests PulseAudio autospawn, the pulseaudio process will end up in the service's cgroup and systemd will stop it along with the service. Considering that the systemd --user instance is run by default in Arch and many ArchWiki pages encourage the usage of systemd user services (regardless if they require DBus or not), I think the problem I outlined is very likely. -- Lahwaacz (talk) 15:37, 7 September 2015 (UTC)
I still believe we should not deviate from upstream by using a not recommended (and as such, less supported) option for the general case. Wiki articles should also mention that systemd --user services can have drawbacks, where applicable. Finally, we can also add an item to PulseAudio#Troubleshooting concerning the matter, and link it as a note in PulseAudio#Running, similar to what was suggested above. -- Alad (talk) 15:52, 7 September 2015 (UTC)
What is the drawback of running PulseAudio as systemd service, other than extra needed configuration (which in Arch means only enabling pulseaudio.socket; I'm not sure if the dbus.service is needed at all)? The quote from upstream documentation in the Pid1's first post must be either outdated or wrong about D-Bus, because I still get the message that module-dbus-protocol is currently unsupported. -- Lahwaacz (talk) 16:44, 7 September 2015 (UTC)
Edit: as per [3], I guess the D-Bus is needed for more features than just the module-dbus-protocol module (which is likely just the last point). I've made this change to describe "autospawn" as the default method and link to the D-Bus section for systemd socket activation: [4] is it OK? -- Lahwaacz (talk) 17:19, 7 September 2015 (UTC)
I am going to make a small phrasing change, but the format looks good. Thanks! Pid1 (talk) 17:27, 7 September 2015 (UTC)
That's great, thanks for the improvements. If there is nothing else, I'd propose to close this discussion and focus on #DBus module. -- Lahwaacz (talk) 19:17, 21 September 2015 (UTC)
Well... v7 will change things around: [5] -- Alad (talk) 19:29, 21 September 2015 (UTC)
Oh. So we'll need to decide whether to keep describing autospawn at all... Lahwaacz (talk) 19:40, 21 September 2015 (UTC)
I have updated the article to reflect the new behavior, as it deviates from upstream's defaults. I have retained a link to upstream, though our behavior is quite different. Any technical or stylistic modifications are welcome. Pid1 (talk) 16:35, 1 October 2015 (UTC)

Equalizer module is unsupported

As of pulseaudio-7.0-2, loading the module-equalizer-sink module results in the following warning:

pulseaudio[535]: W: [pulseaudio] module-equalizer-sink.c: module-equalizer-sink is currently unsupported, and can sometimes cause PulseAudio crashes, increased latency or audible artifacts.
pulseaudio[535]: W: [pulseaudio] module-equalizer-sink.c: If you're facing audio problems, try unloading this module as a potential workaround.

Running qpaeq then makes PulseAudio crash with this error:

pulseaudio[535]: E: [pulseaudio] iface-module.c: Assertion 'pa_dbus_protocol_add_interface(m->dbus_protocol, m->path, &module_interface_info, m) >= 0' failed at modules/dbus/iface-module.c:309, function pa_dbusiface_module_new(). Aborting.

-- Lahwaacz (talk) 08:43, 28 September 2015 (UTC)