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
