First of all, it's written nowhere that the AudioTrack is a blocking system.
Second, when there are 2x the hardware minimum size buffered there is no reason why adding that amount should result in audio artifact. So wether it feels nice or not, that API is not working as advertised. Now about polling vs thread blocking. I agree it can be better in some cases. But I'm using a pre-existing codebase that works that way on Windows, Windows Mobile, Symbian, PalmOS, iPhone, OS X, Linux, and it always work without a problem the way we do things. If AudioTrack had at least one of the bugs I mentioned, it would work fine too. In the end the latency with AudioTrack 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. 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. So I really hope Google will fix their code, and the sooner the better ! On Wed, Feb 17, 2010 at 2:47 AM, Bob Kerns <r...@acm.org> wrote: > 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 -- 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
