[pulseaudio-discuss] Progress since PulseConf

[Tanu Kaskinen]

On Mon, 2013-02-25 at 09:42 +0100, David Henningsson wrote:
> Hi everyone,
> 
> It's been a few months since some of us met in Copenhagen, and since 
> then we've got a new version of PulseAudio out the door. So I think it's 
> time to look back and see if there's any progress on any of these 
> issues, and if not, how we can refuel and get started again :-)

Thanks for this summary!

> Based on Arun's PulseConf notes [1]:
> 
> === Patch review capacity ===
> 
>   * So far, I haven't seen one brought up yet.

This sentence is missing context. I believe you're talking about regular
IRC meetings.

> It looks like we're doing 
> well right now with Tanu doing the bulk of the review work, but it 
> wouldn't hurt if we could share the load a bit better. Colin, as you 
> agreed to setting up the first one, what do you think?

FWIW, I'd like to have the meetings for discussing also other topics
than the current patch review situation. I've been meaning to prod Colin
about this - thanks for bringing this up, so that I don't need to :)

> === Routing infrastructure ===
> 
>   * It looks like there was some progress, but then work seems to have 
> stalled with the last commit being three months ago [2]. Janos/Jaska, 
> how are things going right now, is there something digestible that we 
> can merge into the main tree at this point?
> 
> === Low latency ===
> 
>   * I feel work has been a bit sporadic here.
> 
>     - I once tried to track down a 10 ms+ delay in the kernel which I 
> think was in the i915 driver, and asked for help on LKML but didn't get 
> much. Maybe just doing another try here would be the right thing?
> 
>     - Arun worked a little on changing the buffering refill values to 
> better suit low latency scenarios, but I don't think anything was 
> sufficiently tested and merged. What is your experience?
> 
>     - I suggested to test the maxlength parameter better, and I should 
> probably do that, but haven't got to it yet. Also, I think this is 
> somewhat related to the buffer parameters Arun was working with, so 
> maybe wait until that is merged?
> 
> === Improving (laptop) surround sound ===
> 
>   * No progress, and nobody who signed up for anything AFAIK?
> 
> === Unified cross-distribution ALSA configuration ===
> 
>   * No progress, and nobody who signed up for anything AFAIK?
> 
> === Base volumes ===
> 
>   * No progress, and nobody who signed up for anything AFAIK?
> 
> === Devices with dynamic capabilities (HDMI) ===
> 
>   * I've written some patches that read the HDMI ELD info and that 
> recently have been merged. It also required some kernel patches which 
> will be merged for kernel 3.9 (to support hotplug better). This would at 
> least enable UIs to show the monitor name, which is nice. I'm hoping 
> that Arun will write something that would take the ELD formats and turn 
> into PulseAudio's native format.
> 
>   The question is whether or when to proceed with the dynamic card 
> thing. I somewhat fear regressions since Pierre's email [3]. The 
> question is if the kernel is ready to give us correct information. One 
> strategy could be to wait for GNOME et al to see if we get many bugs in 
> terms of "When I plug in my fancy monitor, GNOME says its name is 
> '!%&#&&#!#'", and perhaps proceed only if there are (almost) no such 
> bugs. What do you think?

I don't really have an opinion. Waiting or not waiting is fine for me.

> === 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.

=== 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.

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

=== 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.

=== 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.

=== "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.

> === 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.

-- 
Tanu