On Thu, 23.07.09 14:38, Zygo Blaxell (zygo.blaxell at xandros.com) wrote: > On Wed, Jul 22, 2009 at 07:37:28PM +0200, Lennart Poettering wrote: > > On Thu, 16.07.09 16:16, Diego E. ???Flameeyes??? Petten?? (flameeyes at gmail.com) wrote: > > > The fix (pending merge on master branch) is available on my branch: > > > > > > http://gitorious.org/~flameeyes/pulseaudio/flameeyes-pulseaudio > > > > > > http://gitorious.org/~flameeyes/pulseaudio/flameeyes-pulseaudio/commit/84200b423ebfa7e2dad9b1b65f64eac7bf3d2114 > [...] > > OTOH the whole feature of enforcing immediate binding is a bit > > snake-oilish. And redundant on prelink-enabled systems. So maybe > > dropping the entire feature wouldn't be that bad after all... > > Coincidentally, for a while now I've been using a modified build > of pulseaudio that has the whole ltdl_bind_now feature stripped out > of it. Why, you might ask? Because without the ltdl_bind_now stuff, > pulse 0.9.15-stable can be built with older versions of libtool and > libltdl-dev (like the ones in Debian Lenny). > > I'm not sure quite what the bind_now stuff is trying to achieve. > The stated purpose is simple enough, but as far as I can tell pulse > isn't doing a bunch of other things that would be needed to avoid > all unexpected delays in real-time code (e.g. preloading and locking code > pages in RAM, preallocating stack, and so forth). It also seems to me > that most of these delays can be avoided by simply executing a complete > cycle of the audio processing loop once, and most human observers won't > notice even the worst case delays in the first loop iteration (and > the humans who do notice can start the PA daemon in advance and/or play some > silent preroll samples with the specific sink inputs they intend to > use). Sure. Enforcing the bind now logic is a bit snake-oilish. But uh, otoh it was relatively easy to do. If you follow the textbook when writing real-time applications you'll find a substantial number of recommendations what to do and what not to do in RT apps. Many of these techniques we cannot use in PA because PA is just one service among many and not the primary reason your power on your computer. For example, locking PA fully into memory basically makes a substantial part of your machine's RAM unavailable to other applications. Given that PA maintains sample caches and stuff like this PA's memory usage can be not exactly small. If we'd lock the entire PA process into memory this would hence result in a reduction of RAM available for everyone else effectively meaning quite a slow down. Instead we decided to go for a "softer" way to handle the risk of swapped out memory (MADV_WILLNEED). So yepp, because PA is part of every user session, and usually just an auxilary part of it we have to compromise. And decide individually on every technology in question if it makes sense to adopt it or not. So memlock() certainly is too expensive, but on the other hand BIND_NOW is very easy to do and cheap, and that's why we did it. > So I'm all in favor of dropping the feature. If the ltdl_bind_now stuff > goes away, can the libtool dependency be downgraded as well? Hmm, uh. The changes between 1.5 and 2.2 were quite substantial, not only in libltdl but also in the autoconf support and stuff. PA requires quite a few very modern external dependencies anyway, so I see not much value in support obsolete versions of libtool. I mean, you now need a very new udev, and a new kernel and a new alsa anyway, so why should lt be the dependency where we still support really old versions? PA needs very new dependencies all over the place, and this won't change anytime soon. Sorry. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
