Thanks Olivier, It is very helpful Olivier, I am just curious about MP3 players, They are able to stop playing with a very small latency. It seems like they would have to repeatedly write into a very small buffer. Do you think that is the case?
My scenario is very similar to the MP3 players. I don’t know when the stop action is going to take place so writing zeros might not work. So the only solution is to use small buffer. I will see how it goes. Thanks On Dec 29, 11:23 am, Olivier Guilyardi <[email protected]> wrote: > On 12/25/2009 02:00 PM, Business Talk wrote: > > > I keep posting this message hoping that maybe somebody from google > > (media group in particular) monitors the group. I need to stop the > > AudioTrack, regardless what's in the buffer, immediately when > > executing the stop/release. The AudioTrack plays in the STREAM mode. > > It appears that the AudioTrack finishes playing what's in the buffer > > and than stops. It seems that it's such a fundamental flaw since there > > are so many audio applications out there. > > I don't think that your question relates to AudioTrack in particular, but to > dealing with audio buffers in general, and especially when these buffers are > too > large. > > On almost any platform and API I can think of, if the audio buffer is large > then > you have to deal with a rather noticeable latency. And I think that your > problem > is indeed about latency. > > Instead of starting/stopping the AudioTrack as you do, which is a quite heavy > operation (thread, locks, IPC, etc..), I would first recommend that you fill > the > buffer with zeros whenever sound has to stop. > > But if your buffer is large then there will be a noticeable delay between the > moment you actually write zeros and the moment the sound becomes silent (yet, > that should be faster than actually calling play() or stop()). > > For instance, I'm quite successfully using AudioTrack with a buffer size of > 4096 > frames, which at 22050Hz, induces (at least) a 185ms delay. That is quite a > lot > IMO, and I don't think you can reduce that in Android's current state. I would > even say than 8092 frames seems a safer choice. > > But many audio applications out there know how to deal with a such latency, > even > if it is about hundreds of milliseconds. It is not always possible, but in > some > case it is, especially if you can: > > (1) measure the output latency > (2) anticipate audio output events > > So that you start playing sounds (or silence) in advance, taking the latency > into account. > > You can approximate (1) with: latency = bufferSize / sampleRate > > Whether (2) is possible or not depends on you app. If it isn't and that > 200-400ms latency is too much for you then I recommend that you star the > following issue to encourage Google to address it as soon as > possible:http://code.google.com/p/android/issues/detail?id=3434 > > -- > Olivier -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
