[pulseaudio-discuss] Progress since PulseConf

[David Henningsson]

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