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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
