bug#38172: WebkitGTK-based browsers: System volume suddenly maxed out when playing audio or video

[Leo Prikler <leo.prikler@student.tugraz.at>]

Am Donnerstag, den 09.01.2020, 21:48 +0100 schrieb Marius Bakke:
> 
> I have a preference for making this field empty initially to have a
> 1:1
> compatibility with the current PA client and daemon configuration
> (i.e. nothing).  Then a follow-up patch can add this new
> configuration,
> perhaps with an explaining comment.
Fair enough.  This would mean I'd have to split 0001 into two, but
okay.

> Does it make sense to have default-script and system-script default
> to
> (file-append pulseaudio "...") and avoid the conditional altogether?
The idea behind it was to have the script itself in the code rather
than asking users to construct a mixed-text-file, but I'm fine either
way.

> This means pulseaudio will start looking in /etc/pulse for
> configuration
> files on foreign distributions too, right?
> 
> I wonder if there is better way to give it configuration
> files.  Perhaps
> by patching the D-Bus service files?  Not a blocker for this series,
> but
> something to consider in case /etc/pulse causes trouble.
This is already addressed by the renewed series I sent to guix-patches. 
I know you already found that, but I'd like to repeat it for those who
thus far have only read this thread.

> End on #t.
As above, but thanks for the hint, I missed the warning it seems.

> [...]
> 
> > From e24016f9a44a113847dd937ac47ab4bdb960236d Mon Sep 17 00:00:00
> > 2001
> > From: Leo Prikler <leo.prikler@student.tugraz.at>
> > Date: Thu, 9 Jan 2020 01:29:13 +0100
> > Subject: [PATCH 3/3] services: Add pulseaudio to %desktop-services.
> > 
> > * gnu/services/desktop.scm (%desktop-services): Add pulseaudio
> > service.
> 
> This will pull in "swh-plugins" which was the original intention
> behind
> pulseaudio-service before this patch series.  Before adding it to
> %desktop-services, I would prefer if the pulseaudio environment
> configuration could be made modular, so that there are no
> configuration
> differences for end users, i.e. they'd have to actively enable the
> LADSPA plugin.
I think adding a field ladspa-plugins, which accepts a list of packages
and adds their "lib/ladspa" would be the right approach here, but I
also feel, that this perhaps deserves its own service unrelated to
pulseaudio.  WDYT?
Either way, I agree on the "having to actively enable" part. 

> As a final note, can you also update doc/guix.texi accordingly?
I will once I've figured out how to best handle these fields.

Regards,
Leo