Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

AudioTrack restarting even after it is stopped

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?

like image 578
Chris Koston Avatar asked Dec 06 '11 05:12

Chris Koston


3 Answers

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:

  1. You don't call the play method until you have some data in the buffer.

  2. You can generate the data fast enough to beat the timeout.

  3. 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 :)

like image 69
Chris Koston Avatar answered Sep 21 '22 06:09

Chris Koston


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.

like image 42
HannahMitt Avatar answered Sep 21 '22 06:09

HannahMitt


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.

like image 20
user1856874 Avatar answered Sep 23 '22 06:09

user1856874