Ok one last post. In AudioRecord, the offset and size are the offset in YOUR buffer.
So this isnt that hard. You can use the same values hardcoded if you want. All you have to do is make sure you are done enough with your buffer before reading again. So you set AudioRecord's buffer to bigger than your own read buffer, then you start an AudioRecorder, then you read a small chunk (YOUR buffer). Now you use that chunk to do something. Then you can read the next chunk. You can use the same offset and size, it will just overwrite the current data in YOUR buffer. Then you use the buffer quick. The only time you will get overflow is if you don't read the data fast enough to keep the AudioRecorder from "looping" around on its own internal buffer (which you told it to allocate), so a bigger buffer would be better here if you don't know if you may have some slow downs here and there. However, even a big buffer won't help if you dont use the data fast enough because eventually Audiorecord will catch up to you if you aren't quick enough - so still you cant be doing tons of processing on the data because you need to read it and get out! So the recorder can keep going. This is the same way that Audiotrack works on output, you have to write faster than it consumes (or at least AS fast - you can do that no problem because write() blocks until data is needed, so technically your audio write thread should be sitting waiting to write most of the time, if not, you are going to get more audio gapping). Hope that helps. -niko On Nov 11, 3:51 pm, niko20 <nikolatesl...@yahoo.com> wrote: > 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
