AudioTrack restarting even after it is stopped

Question

I created a simple application that generates a square wave of given frequency and plays it using AudioTrack in STREAM mode (STREAM_MUSIC). Everything seems to be working fine and the sound plays okay, however when the stream is finished I get messages in the log:

W/AudioTrack( 7579): obtainBuffer() track 0x14c228 disabled, restarting ...

Even after calling the stop() function I still get these. I believe I properly set the AudioTrack buffer size, based on minimal size required by AudioTrack (in my case 6x1024). I feed it with smaller buffers of 1024 shorts.

Is it okay that I'm getting these and should I leave it like that?

Chris Koston · Accepted Answer · 2012-12-03T15:38:28.660

Ok, I think the problem is solved. The error is generated when the buffer is not completely filled with data on time (buffer underrun) . I have no idea what the timeout is but if you experience this make sure that:

You don't call the play method until you have some data in the buffer.
You can generate the data fast enough to beat the timeout.
After you are finished feeding the buffer with data, before you call stop() method, make sure that the "last" buffer was completely filled with data before timeout.

I dealt with the last issue by always waiting a little (until timeout) then sending 1 buffer full of zeroes and finally calling the stop() function.

Keep in mind that you must always send the buffer in smaller chunks, even if you have the big chunk ready. It still bothers me a bit that I'm not 100% sure if that is the right way but the errors are gone so I guess I can live with that :)

score 5 · Answer 2 · answered Apr 02 '12 at 20:59

5

I've found that even when the buffer is technically long enough, and filled with bytes, if they aren't properly formatted (audio shorts converted to a byte array) it will still throw you that error.

answered Apr 02 '12 at 20:59

HannahMitt

1,010
11
14

score 4 · Answer 3 · edited Nov 27 '12 at 14:57

4

I was getting that warning when I instantiated the Audiotrack, called audioTrack.play() and there was a slight delay between the play() call and the audioTrack.write(). If I called play() right before write() the warning disappeared.

edited Nov 27 '12 at 14:57

DarkAjax

15,955
11
53
65

answered Nov 27 '12 at 14:38

user1856874

41
1

That is the point - fill the buffer with data before calling play. Then make sure you can generate the data on time. You will have latency and it depends on your phone (minimal buffer size), sample rate and dynamic resolution you use. Im my case (HTC Desire) 6kB. This is about 3000 16bit mono samples. You can easily calculate the resulting latency taking the sample rate into account. If you use the native audio API you can get much smaller latencies, but still far from iPhone's tiny 5ms... – Chris Koston Dec 03 '12 at 15:36

score 0 · Answer 4 · answered Oct 17 '15 at 14:03

0

I've solved by this

        if (mAudioTrack.getPlayState()!=AudioTrack.PLAYSTATE_PLAYING)
            mAudioTrack.play();
        mAudioTrack.write(b, 0, sz * 2);
        mAudioTrack.stop();
        mAudioTrack.flush();

answered Oct 17 '15 at 14:03

djdance

3,110
27
33

AudioTrack restarting even after it is stopped

4 Answers4