[pulseaudio-discuss] Man page clarifications

[Colin Guthrie]

'Twas brillig, and David Henningsson at 21/10/10 07:49 did gyre and gimble:
> I'm relaying a bug comment to this list, the reporter has ideas about
> the PulseAudio documentation. He originally filed a bug about that when
> adding a pair of lines to ~/.pulse/default.pa and PulseAudio stopped
> working, as he was unaware that it caused /etc/pulse/default.pa not
> being used. I think it's healthy to get bug reports like these, could to
> know what confuses users and what makes PA harder to use.
> 
> Bug report link: https://bugs.launchpad.net/bugs/663019
> 
> ===== Comment from B Bobo begins here ===
> 
> Hmmm, the issue I had was rather that it was not clear that the mere
> existence of ~/.pulse/default.pa effectively blocks the entire contents
> of /etc/pulse/default.pa from being used, instead of being that any
> configuration variable assignments in ~/.pulse/default.pa just override
> the corresponding variable assignments in /etc/pulse/default.pa.

Hmm, default.pa is not doing variable assignments, it's a script with
commands...

> Personally, I think it would be make more sense from a user-perspective,
> and thus generate fewer support issues in the future, if pulseaudio were
> always to read both /etc/pulse/default.pa and ~/.pulse/default.pa,
> taking the values of configuration variables from both of them, with the
> values in ~/.pulse/default.pa overriding the values in
> /etc/pulse/default.pa. 

I don't think that's possible. As I said, they are not doing variable
assignments, but processing commands, in sequence. If you do some sort
of auto-combining thing, then the sequence is lost and that's an
important aspect.

If you want to *change* /etc/pulse/default.pa, then copy it and make
your alterations. If you just want to add a few custom things to the
end, then do something like:

.include /etc/pulse/default.pa
load-module my-custom-module ...

Which achieves that level of functionality.


> Actually, I think it would be clearer and more
> consistent for the users to have it work in the same way for all of the
> files in /etc/pulse/, following the pattern of system-wide defaults in
> /etc/, but override-able on a per-variable basis in the configuration in
> the user's .pulse directory. Some of the files in /etc/pulse/ are
> configuration scripts and the others are configuration files, but for
> both types it should be straightforward to make any variable assignments
> in the ~/.pulse/ version able to override those in the /etc/pulse
> version.

This kind of setup could work for daemon.conf and client.conf as these
are doing simple variable assignments, but it wouldn't work for
default.pa as described above.


> I think the reason so many people recently seem to be getting confused
> and fed up with pulseaudio is that the documentation as a whole does
> have some issues.

Personally I think the reason is more to do with poor integration in
some desktops which I've been trying to solve, but I agree the
documentation needs improvement too (I just expect most users not to
even bother looking! Maybe I'm pessimistic tho'!)


I'll try and incorporate the suggestions here into some kind of update
(i've not read them all yet but certainly will when I get a sec).

Thanks

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]