When you stream buffered data, you have a minimum of two buffers -- at least conceptually. (You can implement it somewhat differently, but it boils down to the same thing the way I look at it).
You fill up one buffer, and give it off to the system or the hardware or another thread. While it is processing it, you write to a second area of memory -- a second buffer. You're then ready to give that second buffer to the system. But usually, the system will have limits as to how many buffers it can accept. For a simple hardware device, this limit is likely to be 1 buffer, with some maximum size. You COULD use more than one buffer, but usually you won't have reason to. But there are definitely reasons why you might -- for example, to allow yourself to rapidly accept incoming data, queuing it up for a slower output device. But whenever you've filled your buffer, you'll want to pass it to the system, as soon as it's ready to accept it. And then once it gives you back your original buffer, you can proceed to fill that. In this case, it generally boils down to "The Audio's buffer", and "Your buffer". "The Audio's buffer" is the one the audio hardware is currently processing, copied from your buffer the last time you called write(). "Your buffer" is the one on the Java side that you get to fill. In the case of audio, the actual hardware buffer isn't going to be simply one buffer, because then there would be gaps as it fills it from the waiting "Your buffer". But you don't need to worry about that -- it's the audio driver's responsibility. Internally, it has its own "the Hardware's buffer", and "The driver's buffer" -- the region of memory that the hardware can read from, and the region of memory that the driver can write to. This all keeps things straight. The receiver of data has its own buffer to read from, that will never be written while it's trying to read, while the sender of data has ITS own buffer to write to, and writes there will never conflict with the reader. Things like ring buffers are still the same idea, but I won't explain how they're the same, because it would make the explanation more confusing. Just hold onto the core idea -- the receiver and sender of data each have their own buffers. On Feb 18, 3:58 am, ani <anish198519851...@gmail.com> wrote: > we would really appreciate if you can explain "both buffers"?Which > buffers are you referring here. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
