In fact what I meant to say as well is in Audiotrack's case, you want a seperate thread that keeps pushing out new data. The write() method will block until new data is needed, which is fine. So as long as your thread can write the data fast enough to keep the buffer full you are golden.
Now as far as AudioRecord I haven't used it much just yet (but soon will). I'm assuming it's similar only the "reverse". By the way PJ, I do use a looped output buffer in my AudioTrack output and I handle it myself. -niko On Nov 11, 3:48 pm, niko20 <nikolatesl...@yahoo.com> wrote: > I've worked with the audio a lot (especially AudioTrack) and I believe > you have everything correct PJ. > > Yesterday I had put together a test app to try playback/record at the > same time and it worked just fine. > > You shouldn't get buffer overflow errors if you make a large buffer > and then read from it as small chunks more quickly. That way you > consume the buffer fast enough so it never gets full. > > It's the same way on AudioTrack for output, you make a buffer large > enough, and then you write in small chunks fast enough to keep it > full. However, in AudioTrack's case, you WILL get a delay the first > time. I've found that AudioTrack won't play until the buffer is full > for the first time. But I suspect that is how Audio buffers work on > any platform. > > -niko > > On Nov 11, 3:09 pm, PJ <pjbar...@gmail.com> wrote: > > > > > If you are worried about delay, you could probably use a small data > > chunk size and a large buffer size. > > > (In my examples, I always used zero for the offset, but you could have > > a large buffer and process the data in small chunks. You would > > process the chunk at offset=0 first, then process the chunk with > > offset = "chunk size", then "chunk size times 2", etc. Eventually you > > have to wrap around back to the beginning of the buffer. I have no > > idea if the API methods handle any of that for you automatically or > > not.) > > > Anyway, that's makes sense in my head, but I don't have that much > > experience with high-performant audio processing. Maybe some experts > > can correct me and/or elaborate on what the proper solution is. > > > -- PJ > > > On Nov 10, 11:23 pm, Bytes <toyvenu.t...@gmail.com> wrote: > > > > Hi, > > > > Thanks for your mails. > > > > I pressume you did in Java. > > > > Ofcourse, we can do the same thing in C++ also. > > > > But the problem is... > > > > "Buffer Overflow "......... > > > > By simply increasing the buffer size won't solve the whole issue. > > > > It may apparently solve buffer overflow, but it will add delay in > > > playing.... > > > > By the way do you know any good documentation about Android Audio > > > internals. > > > > I'm also waiting for Android OS/Audio Expert feedback about this > > > implementation. > > > > Sometimeback, I've posted my audio experiences on another thread > > > >http://groups.google.com/group/android-platform/browse_thread/thread/... > > > > Hopefully this time I can have success. -- 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
