A small correction regarding the 20s hw buffering thing:
We actually already do the revoking for the 2s buffers. It works quite well these days. The big difference between 2s and 20s when doing this however that when you fill up the full 20s with new audio, this might be a quite expensive operation, for example because you decode it from MP3. Now if the user is seeking around and we have to revoke what we already wrote to the hw playback buffer dropping 20s and decoding that again comes at a very steep price, while dropping 2s and decoding that again might still have been acceptable. So, the idea I was ventilating at LPC (or at least wanted to explain, I might not have been clear on this) was that we use some kind of stochastic model so that for some time after the last seeking we don't fill up the full 20s but only 5s or so, which is much cheaper. And then when during the next iteration we noticed that we never had to revoke it, we generate 10s for the next iteration. And when after it we noticed that we didn't have to revoke it we go for the full 20s for the following iterations. However, if the user seeks around during that time we go back to filling up only 5s again. We'd do that mechanism under the assumption that if the user seeks around he does that in "bursts", i.e. seldom, but when he does it he does it a couple of times shortly following on each other. And we don't want to pay the price for having to decode the full 20s again each time.