Lennart Poettering wrote: > On Wed, 13.02.08 18:34, Colin Guthrie (gmane at colin.guthr.ie) wrote: > >> Lennart Poettering wrote: >>> Hmm, I wonder if there are any drawbacks of this way to start PA. Does >>> gnome-session still upload the samples correctly if it doesn't start >>> esd/PA by itself? It has been a while since I last had a look on the >>> g-s source code. >>> >>> If that's not a problem, than I might do a similar change on Fedora, too. >> Not 100% sure about that one. I certainly get my login sound but I have >> been a little confused about not seeing samples in the cache.... >> although this is no doubt due to me restarting pulseaudio since logging >> in (I generally don't log out/in much provided my suspend is behaving..). >> >> I'll let you know. >> >> One other thing for fedora package (not sure if it applies) is ESD >> autospawn. I've had to ship a /etc/esd.conf with "auto_spawn=0" in it >> otherwise libesound will try to run /usr/bin/esd by default (which is >> obviously symlinked to esdcompat). Alternative would be to hack >> libesound to make no_autospawn default to 1 but somehow the config file >> seemed less hacky and didn't change the defined behaviour of >> libesound. > > Autospawning = evil. Don't do it. I'm trying not to :) The mistake I made was not including an esd.conf file to stop libesound from doing it by default :) > Hmm, when I hacked the auto-spawning code I made sure that it worked > event for the ESD drop-in stuff. Are you suggesting that this doesn't work? No, there is no bug in pulse here, I just had a bug in my packaging of the pulseaudio-esound-compat package where I did not provide an /etc/esd.conf file. When this file does not exist, the *libesound* autospawning was turned on by default which resulted in pulse being auto spawned via /usr/bin/esd -> esdcompat Like I say it may not be an issue on fedora's libesound if it's been tweaked accordingly. > Hmm, if I remember correctly: GNOME will fallback to non-cache event > sound playback if a cached sample for the event is not cached. That > might be the reason why event sounds still work for you, although > nothing is in the cache. Fair enough. Certainly the sounds are cached at login as I think I reported back elsewhere so that's good :) Col
