A more general use of double buffering is when 2 entities A and B need to pass each other information in a situation where it is crucial that B receives an uninterrupted flow of data, and where a large single buffer is not feasible. A and B may be 2 parts of the same program, 2 different processes on the same computer etc.
To do double buffering, you need 2 buffers b1, b2 and some communication mechanism between A and B. Often this is a set of flags or callbacks.
Generally A fills up the buffers, then tells B that it is ready. B will then start reading out of b1. When B is done it tells A that it is through with b1, and starts reading from b2. When everything goes to plan, by the time B has finished reading b2, A has filled b1 with some tasty new data and so B can read from b1 again. This continues as long as A and B feel like it. As you can see this will usually mean B never has to wait for data (at the expense of a little more memory overhead).
Now for an example of some hardcore double buffering action! Let us travel back in time to the days of Mac OS 9, in particular lets have a look at the Sound Manager API that was present until Mac OS 9.x, where my good friend SndPlayDoubleBuffer lives. The brightest among you will probably have guessed that this function uses double buffering. It was mainly used to be able play background music or looping sounds continously without having to load too much of the sound data into memory at a time. The need for double buffering is obvious here. If the sound hardware has to wait for data your music is going to get all horrible and choppy. You gave SndPlayDoubleBuffer buffers and a callback and when it had finished reading from one of the buffers it would call your callback and tell you it was ok to refill that buffer.
SndPlayDoubleBuffer is not included in the Carbon specification. After many years of loyal services, its home is now the great header file in the sky.