[pulseaudio-discuss] temporary vs persistent state data

[Damon Harper]

hello lennart -

i certainly understand that it's low-priority - i actually haven't
given it any further thought myself since sending the message, though
i think i should set up some symlinks or something for now.

i will certainly file it as a bug report.

since then i've actually had problems with a couple of programs - the
game wesnoth (wesnoth.org) loses its audio or locks up if i have pulse
set up as the default alsa module, and there's an already-known
problem with alsaplayer.  i worked around it for now by running pulse
overtop of alsa dmix, though that's less than ideal.  still love pulse
itself - i will have to file a bug report on the wesnoth problem as
well, though i don't really have a lot to go on.

-damon

On 12 Jul, Lennart Poettering wrote:

> On Thu, 14.06.07 13:07, Damon Harper (dl+pulseaudio-discuss at usrbin.ca)
> wrote:
> 
> Hi!
> 
> > 
> > i've just installed and set up pulseaudio and i am more than impressed
> > by it - bravo!  it is an elegant system and a much-needed one for the
> > unix world, i think.
> 
> Thank you.
> 
> > 
> > i'm a bit of a weird masochist who rolls his own distro and packaging
> > system for a four-computer network, and i have noticed one problem
> > with the way pulse works when it is set up as a system-wide daemon -
> > it stores both temporary and persistent data in the same place
> > (/var/run/pulse by default).
> > 
> > for instance, the gconf data and volume-restore.table file *should*, i
> > presume, be maintained across reboots.  on my system, i use /var/run
> > strictly for temporary data like pid files and sockets and it is wiped
> > out at each reboot - so the persistent pulse data disappears.
> > normally persistent data should go under /var/lib or /var/state.
> 
> Hmm, you're probably right with this interpretation of the FHS. Could
> you please file a bug, so that I don't forget to fis this?
> 
> > on the other hand, pulse's pid files and sockets *should* be treated
> > as temporary data and could be fair game to be wiped out if they
> > remain when pulse is no longer running.
> > 
> > i was initially going to set up a system of symlinks to take care of
> > this, but then i started looking at the pulse source.  my general idea
> > would be to split the PA_SYSTEM_RUNTIME_PATH up into two components,
> > one for temporary (/var/run/pulse) and one for persistent
> > (/var/lib/pulse or /var/state/pulse) files.  then each component that
> > needs to store files can choose the appropriate path.
> > 
> > complications:
> > 
> > - could affect existing programs?  but i don't think so, as most would
> > reference pid files and sockets which remain in /var/run/pulse.
> 
> Shouldn't hurt to much, since noone should be accessing these files
> without going through libpulse.
> 
> > - how does this interact with the per-user daemon operation?
> 
> When the daemon is running per user the data is split up cleanly
> anway. Data that should be save is stored in ~/.pulse and dynamic data
> is stored in /tmp somewhre.
> 
> > 
> > - ideally, gconf lock files would go with the temporary data and gconf
> > data with the permanent, though i don't know enough about gconf to> know
> if this is easy or even plausible.
> 
> Humm. I doubt that gconf can do that.
> 
> > any thoughts?  is this feasible / wanted / worth putting some effort
> > into?  are there complications i haven't considered?
> 
> Makes a lot of sense. Please file a bug and I will eventually fix
> this. (Though this is actually low-priority for me, I must admit)
> 
> Thank you for reporting this!
> 
> Lennart
> 
> -- 
> Lennart Poettering                        Red Hat, Inc.
> lennart [at] poettering [dot] net         ICQ# 11060553
> http://0pointer.net/lennart/           GnuPG 0x1A015CC4
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss