[pulseaudio-discuss] Improvements related to configuration

[David Henningsson]

On 03/25/2013 03:35 PM, Tanu Kaskinen wrote:
> On Mon, 2013-03-25 at 09:36 +0100, David Henningsson wrote:
>> On 03/22/2013 06:01 PM, Tanu Kaskinen wrote:
>>> Hello,
>>>
>>> I added another GSoC idea to the wiki[1], and it's also copied below.
>>> Does the idea make sense? Is there anything in it that should be
>>> changed?
>>
>> Not sure about if I would recommend this one to a GSoC student. It feels
>> like we have quite some stuff to figure out w r t to directory moving,
>> conf splitting etc, that aren't straight laid out yet. If we get all
>> that work thought out, then okay, but if we're unsure of what to do, the
>> GSoC student will be even more confused.
>
> Fair point, I'll remove the project idea from the wiki for now.
>
>>
>>> === Improvements Related to Configuration ===
>>>
>>> '''Problem statement:''' There are a couple of separate problems:
>>>    * If setting some option in a configuration file doesn't seem to have
>>> any effect, chances are that it's being overridden in some other file,
>>> but which file? It's slightly tedious to manually look in several
>>> directories and check the file contents. It's even more cumbersome when
>>> debugging a problem remotely, when it's necessary to explain every step
>>> that needs to be performed.
>>>    * Changing a configuration file requires restarting the server before
>>> the change takes effect.
>>>
>>> '''Suggested solution:'''
>>>    * When reading configuration files, the daemon should store the origin
>>> file of each option separately. This information should then be made
>>> possible to query by clients. Then, pactl (a command-line utility for
>>> interacting with the server) should be extended to provide a command
>>> that prints the configuration of the running server, and also the origin
>>> file of each option. This functionality would probably apply only to the
>>> "ini-style" configuration files. Those cover most of the !PulseAudio
>>> configuration, with the notable exception of the startup script. It
>>> might be useful to also record the loaded startup script(s) so that the
>>> startup sequence can be queried for debug purposes.
>>>    * Sending SIGHUP to the server process should cause it to reload its
>>> configuration. This too would probably apply only to the "ini-style"
>>> configuration files, not to the startup script. It's probably not
>>> possible to make all configuration options changeable at run-time, but
>>> that's OK.
>>
>> Hmm. This sounds like a lot of complexity for little gain. And potential
>> bugs only affecting those who are using this not-so-widely-used feature,
>> I assume.
>
> Are you referring to the second point only, or both points?

Mostly the second, but if it only has support for the .ini-style conf 
files, maybe the first as well. After all, it seems like we more often 
want to change default.pa than daemon.conf.

> I don't think the second point is for little gain. Sure, just reloading
> the configuration on SIGHUP (or whatever mechanism) isn't that
> interesting in itself, but runtime-changeable configuration is required
> anyway in order to support configuration GUIs.

Well, the simpler solution of just restarting PA when you click "apply", 
or possibly just give a warning message "Settings will not take affect 
until PA is restarted" is not to be forgotten.

> I considered adding a
> client API for writing configuration options to the project idea too,
> but there seemed to be enough stuff in the idea already, and having such
> an API has some problems (mentioned in this[1] message) for which we
> would need to agree on a solution first.
>
> Originally, I also had another use case in mind: on Harmattan,
> applications could install configuration files for a PulseAudio policy
> module, and during installation PulseAudio's configuration had to be
> reloaded. Since there was no support for doing that at runtime, each
> application was expected to restart PulseAudio in their postinst script,
> which was obviously not optimal (there could be music playing in the
> background, for example). Thinking this a bit more, this probably isn't
> a very relevant use case. Harmattan is dead, and we don't have other
> examples where random applications would install configuration files for
> PulseAudio. When PulseAudio itself is updated, the configuration may
> change, but in that case it's better to restart PulseAudio anyway, since
> the code has probably changed too. It would be nice to have a "deferred
> restart" functionality that would restart the daemon once it becomes
> idle, to avoid interrupting active streams, but that's a separate
> discussion.
>
> [1] http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/16053/focus=16109
>
>> If we go with this, I think we should make it a whitelist rather than a
>> blacklist; i e, figure out a few parameters which are both useful to
>> change at runtime and don't have implications all over the system.
>
> Yes, that's how I envisioned it to work.
>
>> Also, why SIGHUP? A native protocol extension seems more intuitive to me.
>
> AFAIK, SIGHUP is sort of standard for telling daemons to reload their
> configuration.

Hmm, googling on that, it seems to be used in a few other daemons, but 
it seems to be an adhoc standard rather than something formalised.

> But thinking this a bit more, I agree that having this in
> the client API would be better, because I think pactl should have
> support for this, and it would be very confusing if pactl would send the
> signal to the local server if it's otherwise configured to use a remote
> server. Supporting SIGHUP still as an alternative should be pretty
> trivial, though.

Ok.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic