On 02/27/2013 06:44 PM, Tanu Kaskinen wrote:
On Mon, 2013-02-25 at 09:42 +0100, David Henningsson wrote:
=== Splitting of configuration ===
* I think we're currently waiting for Tanu to do some work on this
issue and come up with a more concrete proposal, is that correct?
Yes, it probably is correct. I didn't know/think that people were really
waiting for me, but now that I think about it, I probably did promise to
do some work on this. I haven't yet done anything, but I'll try to focus
on this "soon".
As for proposals, here are some:
=== What to do first ===
There are two separate improvements for the configuration handling that
were discussed: splitting the configuration into "core", "policy" and
"hardware" bits, and moving all configuration under $(datadir) with
support for overriding in $(sysconfdir) and $XDG_CONFIG_HOME. I propose
that the configuration move is done first, because I feel that it would
provide a more solid base for thinking about how the configuration split
should be implemented.
Hmm, reading the XDG spec, it says "Default configuration files should
be installed to $sysconfdir/xdg/subdir/filename with $sysconfdir
defaulting to /etc."
Would it feel weird to put the default in /etc/xdg/pulseaudio/ , with
overrides in /etc/pulseaudio? I'm not an experienced admin, so I'm not
sure how other software does it.
=== Including system configuration files from user configuration ===
If /etc/pulse is only used for overriding the upstream defaults, a
situation may arise where a user has ~/.config/pulse/default.pa, and he
would like to include the system version of the file,
but /etc/pulse/default.pa doesn't exist. In that
case, /usr/share/pulseaudio/config/default.pa should be included, but
how does the user express that in the configuration file? A couple of
options:
.ifexists /etc/pulse/default.pa
.include /etc/pulse/default.pa
.else
.include /usr/share/pulseaudio/config/default.pa
.endif
.include[search_start_level=system] default.pa
The "search_start_level" option would accept values
"base" (/usr/share/pulseaudio/config), "system" (/etc/pulse),
"user" (~/.config/pulse) or
"user-machine" (~/.config/pulse/machine-id-<machine-id>). The default
would be "user-machine".
The first option is annoyingly verbose, but it's easy to understand and
supported today. I would really like this to be possible with one line,
like in the second example, but I think it's more important that it's
obvious what the include command does. I don't think it's obvious what
"search_start_level=system" means, and I can't think of any better
syntax, so if better proposals don't appear, I prefer the clear but
verbose option.
We could also add something like a:
.include-fallback
or
.include-default
where this "include-fallback" or "include-default" would take the
current file's "override level" and continue from there.
=== Including relative paths ===
Currently, ".include somefile.conf" treats somefile.conf as a path
relative to the directory of the current file. I propose that it's
changed so that ".include somefile.conf" does a full search: first in
the user configuration directory, then in the system directory, and so
on. The reason is that if the system configuration is split into several
files, without this change only the "root" file could be overridden by
the user, because the non-root files would never be searched in the user
directory (we could implement some extra syntax so that the system
configuration could use ".ifexists $USER_CONF_DIR/somefile.conf", but I
don't think that's a better solution than doing a full search for
relative paths).
...hmm, given this example, we could instead just extend ".include" to
never be recursive, i e skip files that are already included. Thus,
writing ".include default.pa" inside default.pa would be perfectly valid
(but look a bit confusing perhaps?).
=== Machine specific user configuration ===
Configuration files should be searched in
~/.config/pulse/machine-id-<machine-id>/ too. The reason is that the
configuration can be machine specific. I don't remember that anyone
would ever have requested this feature, but this seems like the right
thing to do, and adding another directory to the list of search paths
should be trivial.
And another file to add to the list of things to check when things go
wrong, perhaps.
=== Moving state files to $XDG_DATA_HOME ===
I think a "configuration file" means a file that is meant to be directly
edited by the user. The various module-foo-restore database files are
not configuration files, so they should be moved under $XDG_DATA_HOME.
I don't have a strong opinion on this one, not sure if it's worth the
effort.
=== "pulse" vs. "pulseaudio" ===
There's an annoying inconsistency in the directories that pulseaudio
uses: "pulse" vs. "pulseaudio". There's /usr/share/pulseaudio, but
otherwise we use "pulse" in paths. I would prefer to use "pulseaudio"
everywhere, but I don't think changing the current scheme is worth the
effort. I brought this up, however, because if others think that yes,
this change makes sense and is worth the effort, I could work on this
too while files are moved around anyway.
I prefer pulseaudio over pulse too. I guess that at least every "new"
subdirectory that is created due to this move should be "pulseaudio"
rather than "pulse"?
Also the .config/pulse dir is quite new, perhaps we can just change it
to .config/pulseaudio ?
=== Better drain/underrun reporting ===
* No work so far; and I can reiterate that it feels like it's quite
far down on the priority list. Do you agree or should I try to start
working on this (compared to other stuff)?
I don't really have an opinion. I expect you to do what you want. But if
I had to choose between "low latency", "HDMI improvements" and "fixing
the drain bug" (I guess these were the things that you had some plans to
work on?), it would not be an easy choice. I'd probably pick "low
latency", but I'd assign pretty much the same priority to all three
tasks.
Ok, I picked the drain bug because I figured it would be the least
effort of the three...which is not to say it's easy :-)
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
