![]() ![]() 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()).įor 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. _currentAngle = _currentAngle + _angleIncrement _angleIncrement = (float) (2.0f * Math.PI) * _freq / _sampleRate Update angleIncrement, as the frequency may have changed by now OutBuff = (short) (Short.MAX_VALUE * ((float) Math.sin(_currentAngle))) Short outBuff = new short // (buffer size in Bytes) / 2 The worker thread's buffer is being populated (via tick()) as such: public short tick() _audioTrackOut = new AudioTrack(AudioManager.STREAM_MUSIC, _sampleRate, AudioFormat.CHANNEL_OUT_STEREO, AudioFormat.ENCODING_PCM_16BIT, _buffSize, AudioTrack.MODE_STREAM) My Audio track is set up as such: _buffSize = AudioTrack.getMinBufferSize(sampleRate, AudioFormat.CHANNEL_OUT_STEREO, AudioFormat.ENCODING_PCM_16BIT) The audio data is being written like this: _audioTrackOut.write(fromWorker, 0, fromWorker.length) Īny help would be greatly appreciated. I found a similar problem here: Android AudioTrack buffering problems 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. 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. 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).I love that it’s simple, but it’s a little bit too simple. Its almost impossible to choose a specific frequency on the high end. There’s a plus and minus button that moves up or down one single hz, which is practical at 60 hz, but silly at 16,237. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |