Android Audio - Streaming sine-tone generator odd behaviour

Question

first time poster here. I usually like to find the answer myself (be it through research or trial-and-error), but I'm stumped here.

What I'm trying to do: I'm building a simple android audio synthesizer. Right now, I'm just playing a sine-tone in real time, with a slider in the UI that changes the tone's frequency as the user adjusts it.

How I've built it: Basically, I have two threads - a worker thread and an output thread. The worker thread simply fills a buffer with the sine wave data every time its tick() method is called. Once the buffer is filled, it alerts the output thread that the data is ready to be written to the audio track. The reason I am using two threads is because audiotrack.write() blocks, and I want the worker thread to be able to begin processing its data as soon as possible (rather than waiting for the audio track to finish writing). The slider on the UI simply changes a variable in the worker thread, so that any changes to the frequency (via the slider) will be read by the worker thread's tick() method.

What works: Almost everything; The threads communicate well, there don't seem to be any gaps or clicks in the playback. Despite the large buffer size (thanks android), the responsiveness is OK. The frequency variable does change, as do the intermediate values used during the buffer calculations in the tick() method (verified by Log.i()).

What doesn't work: For some reason, I can't seem to get a continuous change in audible frequency. When I adjust the slider, the frequency changes in steps, often as wide as fourths or fifths. Theoretically, I should be hearing changes as minute as 1Hz, but I'm not. Oddly enough, it seems as if changes to the slider is causing the sine wave to play through intervals in the harmonic series; However, I can verify that the frequency variable is NOT snapping to integral multiples of the default frequency.

My Audio track is set up as such:

_buffSize = AudioTrack.getMinBufferSize(sampleRate, AudioFormat.CHANNEL_OUT_STEREO, AudioFormat.ENCODING_PCM_16BIT);
_audioTrackOut = new AudioTrack(AudioManager.STREAM_MUSIC, _sampleRate, AudioFormat.CHANNEL_OUT_STEREO, AudioFormat.ENCODING_PCM_16BIT, _buffSize, AudioTrack.MODE_STREAM);

The worker thread's buffer is being populated (via tick()) as such:

public short[] tick()
{
    short[] outBuff = new short[_outBuffSize/2]; // (buffer size in Bytes) / 2
    for (int i = 0; i < _outBuffSize/2; i++) 
    {
        outBuff[i] = (short) (Short.MAX_VALUE * ((float) Math.sin(_currentAngle)));

        //Update angleIncrement, as the frequency may have changed by now
        _angleIncrement = (float) (2.0f * Math.PI) * _freq / _sampleRate;
        _currentAngle = _currentAngle + _angleIncrement;    
    }
    return outBuff;     
}

The audio data is being written like this:

_audioTrackOut.write(fromWorker, 0, fromWorker.length);

Any help would be greatly appreciated. How can I get more gradual changes in frequency? I'm pretty confident that my logic in tick() is sound, as Log.i() verifies that the variables angleIncrement and currentAngle are being updated properly.

Thank you!

Update:

I found a similar problem here: Android AudioTrack buffering problems The solution proposed that one must be able to produce samples fast enough for the audioTrack, which makes sense. I lowered my sample rate to 22050Hz, and ran some empirical tests - I can fill my buffer (via tick()) in approximately 6ms in the worst case. This is more than adequate. At 22050Hz, the audioTrack gives me a buffer size of 2048 samples (or 4096 Bytes). So, each filled buffer lasts for ~0.0928 seconds of audio, which is much longer than it takes to create the data (1~6 ms). SO, I know that I don't have any problems producing samples fast enough.

I should also note that for about the first 3 seconds of the applications lifecycle, it works fine - a smooth sweep of the slider produces a smooth sweep in the audio output. After this, it starts to get really choppy (sound only changes about every 100Mhz), and after that, it stops responding to slider input at all.

I also fixed one bug, but I don't think it has an effect. AudioTrack.getMinBufferSize() returns the smallest allowable buffer size in BYTES, and I was using this number as the length of the buffer in tick() - I now use half this number (2 Bytes per sample).

Loyola

What event do you use for _freq changing? Is it really changes by 1Hz every time? Sorry, I don't clearly understand your What doesn't work section. Could you provide a full working code sample or a synthesised sound fragment to make it possible to hear your problem. For sound fragment: raw sound data format is ok - just write your buffer to file, not to audio card. For example, 16 bit/signed/mono/44100 Hz. – Wilheminawilhide

To change _freq, I'm using an OnSeekBarChangeListener that writes a new int value to _freq via onProgressChanged(). However, I've also tried using buttons (up/down) that increment the frequency by 1 Hz, and there is only an audible difference in pitch after many, many increments (such that the sound jumps in pitch by about a 3rd or 4th, rather than 1Hz). Here's an example of what's happening; This is what I hear when I slowly slide the slider up and down, incrementing the frequency in 1Hz increments. (from ~200 - ~1000Hz): sendspace.com/file/tpxuwr – Loyola

I found a similar problem online, but its proposed solution did not help - see the update above. – Loyola

What returns AudioTrack.getMinBufferSize() on your device with your settings? – Wilheminawilhide

Using mono, 16bit PCM and a sample rate of 22050, getMinBufferSize() returns 4096. In the last edit to my original post, I mention that I updated my code to divide this number by 2 when populating the buffer with samples (as I need 2048 shorts to fill a buffer of 4096 Bytes). – Loyola

How many buffers you use? I mean, how many samples you fill in your buffer(s) in the worker thread during one write() in the output thread? – Wilheminawilhide

The worker thread and the output thread use a linkedBlockingQueue to pass the data from the former to the latter. Once the worker thread adds one full buffer to the queue, it notifies the output thread that new data is available. The output thread then removes this data from the queue and writes it to the audio track. The worker thread will ONLY write a new buffer (via tick()) when the linkeBlockingQueue is empty. So, there is only ever at most 1 buffer waiting to be written to the audio track. (The linkedBlockingQueue only ever contains 0 or 1 short[]). – Loyola

Could you check increasing the _freq variable between tick() calls? Something like if (oldFreq != _freq) { Log.d(TAG, "Freq difference: " + (_freq - oldFreq)); oldFreq = _freq; } inside the tick() method. – Wilheminawilhide

I just tried that, and I can verify that the _freq variable is changing as it should. In LogCat I can see the correct changes in frequency, and it sounds correct for about 4-5 seconds. After this point, the sound only changes frequency in large increments, but the values in LogCat indicate that the frequency is changing in small increments. – Loyola

Answer 1

I've found it!

It turns out the problem has nothing to do with buffers or threading.

It sounds fine in the first couple of seconds, because the angle of the computation is relatively small. As the program runs and the angle grows, Math.sin(_currentAngle) begins to produce unreliable values.

So, I replaced Math.sin() with FloatMath.sin().

I also replaced _currentAngle = _currentAngle + _angleIncrement;

with

_currentAngle = ((_currentAngle + _angleIncrement) % (2.0f * (float) Math.PI));, so the angle is always < 2*PI.

Works like a charm! Thanks very much for your help, praetorian droid!

Loyola

Damn, I forgot about 2*Pi normalization! I've seen it in my own old code, but missed its absence in yours. But I thought that overflow of the angle variable should give effect of clicks and your sample sounds different. Anyway, I'm glad that you solved your problem. – Wilheminawilhide