Re: [pulseaudio-discuss] Controlling where module-rtp-send sends multicast packets?
On Fri, 15.02.08 15:18, Kevin Fox ([EMAIL PROTECTED]) wrote: Are there any plans to support rtp syncing in the future? Yes. The hard part is actually already done. It's just a matter of putting things together. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio automatic startup
Lennart Poettering wrote: On Wed, 13.02.08 18:34, Colin Guthrie ([EMAIL PROTECTED]) 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 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio automatic startup
Lennart Poettering wrote: 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 And that doesn't work for you? It should work. I carefully made sure to make PA as compatible to esd as possible, and that includes handling libesd-based autospawning of PA. If it doesn't work, than I broke something. It works. Everything works!! The only problem was in my package which didn't ship an esd.conf file (we do not want esd to autospawn by default). The default config file with the real esound has a config file that does not autospawn by default so when converting to use pulse over esound I inadvertently changed the default behaviour. I only mention this in case you do not ship an esd.conf in your fedora package and have the same issue as me! I've not picked through the fedora rpms lately so it may not be an issue at all! I didn't mean this to be a discussion, just a heads up, so sorry if I've misled you a bit here :p 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 :) Hmm, so you say that if PA is started before gnome-session, then it will still properly upload the samples? That would be great. Certainly seems to, tho' I've only got observation here rather than facts from picking through the gnome-session stuff. Col ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio automatic startup
On Sat, 16.02.08 14:29, Colin Guthrie ([EMAIL PROTECTED]) wrote: 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 And that doesn't work for you? It should work. I carefully made sure to make PA as compatible to esd as possible, and that includes handling libesd-based autospawning of PA. If it doesn't work, than I broke something. 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 :) Hmm, so you say that if PA is started before gnome-session, then it will still properly upload the samples? That would be great. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Controlling where module-rtp-send sends multicast packets?
On 2/16/08, Lennart Poettering [EMAIL PROTECTED] wrote: On Fri, 15.02.08 15:18, Kevin Fox ([EMAIL PROTECTED]) wrote: Are there any plans to support rtp syncing in the future? Yes. The hard part is actually already done. It's just a matter of putting things together. This is a good way to keep clocks on a LAN tightly synchronized. Since it is LAN based it can be more accurate than NTP. http://en.wikipedia.org/wiki/Precision_Time_Protocol http://ptpd.sourceforge.net/ -- Jon Smirl [EMAIL PROTECTED] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
