Difference between revisions of "Talk:PulseAudio"

From ArchWiki
Jump to: navigation, search
m (Proposed Corrections: Reply to lahwaacz)
m (Proposed Corrections: Clarification.)
Line 75: Line 75:
 
:::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.
 
:::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.
 
::: [[User:Pid1|Pid1]] ([[User talk:Pid1|talk]]) 15:01, 7 September 2015 (UTC)
 
::: [[User:Pid1|Pid1]] ([[User talk:Pid1|talk]]) 15:01, 7 September 2015 (UTC)
 +
 +
::::I should note that I am referring to the sound interruptions, and not [[#DBus module]].
 +
:::: [[User:Pid1|Pid1]] ([[User talk:Pid1|talk]]) 15:15, 7 September 2015 (UTC)

Revision as of 15:15, 7 September 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)

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)

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