[pulseaudio-discuss] Improvements related to configuration

[Tanu Kaskinen]

On Mon, 2013-03-25 at 16:35 +0200, 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:
> > > '''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?
> 
> 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. 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

Sorry, the link points to a wrong message. I meant this (the section
starting with words "I'm also having second thoughts"):
http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/16053/focus=16106

-- 
Tanu