>From your description, it sounds like everything is happening just as designed, and as it should, and that the only problem is that you feel your program isn't complicated enough.
Is that a fair assessment? You get the right result. Your code spends most of its time waiting for the hardware, which right on schedule, frees up a buffer, which you fill, and block waiting for the next. All without any extra effort on your part, and no inefficient polling, etc. Instead of this very simple and efficient copy operation, you want it to be non-blocking, so you can poll the buffers (how often?), and implement complicated and bug-prone logic to manage the available buffer space yourself? Why? The only advantage I can see for all that extra complexity, is that you reduce the latency between your input data and output to the native buffers. But you can get the same result by reducing your buffer size. Non-blocking IO calls make a lot of sense in an environment with no threading, or with a high degree of parallelism (so that the necessary number of threads becomes a scaling problem, as in web servers). Neither of those situations applies here. Seems to me, the solution to your problem is just to smile and be happy! On Feb 16, 6:57 am, Steve Lhomme <rob...@gmail.com> wrote: > Hello, > > I'm trying to write an audio sink for my application. I am using the > AudioTrack class and it works pretty well. In other words I get the > audio to play correctly (stream mode). > > I am using it in C code via the NDK, but that shouldn't matter. The > AudioTrack creation and feeding is done in a separate thread from the > UI. > > However, I am having issues with the speed in which it's handling the > AudioTrack.write() call. As you can see in the following traces, it > takes between 50 ms to 70 ms to write 6144 shorts (or 3072 samples). > At 44100 Hz that's almost the duration of the buffer I'm writing ! I > assume that's because all the hardware buffers are used and it's > waiting to write. But I think it should rather exit right away, saying > no buffer was written (like during the pre- roll at the beggining). -- 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
