The 70 ms here isn't due to the blocking nature, but due to the buffer size. With a 2.5 ms buffer size, you'd be able to stop the sound in 5ms even when both buffers were full. It really has nothing to do with blocking/non-blocking, which simply has to do with who has to do the blocking and checking for buffers full/available.
I take it 70 ms is the minimum your hardware supports? If so, non- blocking won't solve it, and you probably need different hardware. The fact that they even HAVE a minimum suggests to me that we'e talking about transferring to hardware buffers. Except for embedded devices, it's been a long time since software wrote the DAC registers directly. But what about that 500 ms? That would seem to be more under your control. You can do your work in smaller chunks. The scheduler is the other thing that'll kill you -- especially if you had smaller buffer sizes. If you're doing work in other threads, you'd want to tune it so you're doing work in small enough chunks that your output thread can run in a timely way. A non-blocking protocol does let you be more explicit about this -- essentially write your own scheduler. But you can get the same result with an "audio pipeline" approach, where you move small buffers of data through each stage of your processing, in a single thread, and if the UI sets a flag that you should be doing something different, you just exit out of that pipeline wherever you are in the processing, and start up the new pipeline. If you want to try to use up more processor on the earlier parts of your task, to protect against underruns, you can use two threads, with a larger number of small buffers mediating between them. The smaller buffers keep the initial latency small, while the larger number of buffers still allows the upstream processing to get further ahead. On Feb 16, 11:14 pm, Steve Lhomme <rob...@gmail.com> wrote: > I can also say that a blocking AudioTrack would suck for a DJ software > where 70 ms of latency to do an action is terrible. 5 ms would be > acceptable, and that's also about as much time we use for polling. > ...and because of the way our "feeding" > threads work, it can take up to 500 ms between the time the user > presses pause and the time the thread using AudioTrack is actually > able to handle it. -- 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
