Android音频-流式正弦波发生器奇怪的行为

Question

第一次海报在这里。我通常喜欢自己找到答案（通过研究或反复试验得出），但是我很困惑。

我要做什么： 我正在构建一个简单的android音频合成器。现在，我只是在实时播放正弦音，UI中的滑块会随着用户的调整而改变音的频率。

如何构建它： 基本上，我有两个线程-
工作线程和输出线程。每当调用其tick（）方法时，工作线程就用正弦波数据填充一个缓冲区。一旦缓冲区被填满，它会警告输出线程数据已准备好写入音频轨道。我使用两个线程的原因是因为audiotrack.write（）阻塞，并且我希望工作线程能够尽快开始处理其数据（而不是等待音频轨道完成写入）。UI上的滑块只是更改了工作线程中的变量，因此（通过滑块）对频率的任何更改都将由工作线程的tick（）方法读取。

什么有效：
几乎所有东西；线程之间的沟通很好，播放中似乎没有间隙或点击。尽管缓冲区很大（感谢android），但响应能力还不错。频率变量确实会发生变化，tick（）方法（由Log.i（）验证）的缓冲区计算过程中使用的中间值也会发生变化。

什么不起作用：
由于某种原因，我似乎听不见频率的连续变化。调整滑块时，频率会逐步变化，通常为四分之一或五分之一。从理论上讲，我应该听到1Hz的微小变化，但不是。奇怪的是，似乎对滑块的更改导致正弦波在谐波序列的间隔中播放。但是，我可以验证该频率变量未捕捉到默认频率的整数倍。

我的音轨设置如下：

_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);

工人线程的缓冲区是这样填充的（通过tick（））：

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;     
}

音频数据是这样写的：

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

任何帮助将不胜感激。如何获得逐渐的频率变化？我非常有信心自己在tick（）中的逻辑是正确的，因为Log.i（）验证变量angleIncrement和currentAngle是否已正确更新。

谢谢！

更新：

我在这里发现了一个类似的问题：AndroidAudioTrack缓冲问题
该解决方案提出，必须能够足够快地为audioTrack生成样本，这才有意义。我将采样率降低到22050Hz，并进行了一些经验测试-
在最坏的情况下，我可以在大约6毫秒内填充缓冲区（通过tick（））。这绰绰有余。在22050Hz时，audioTrack为我提供了2048个样本（或4096字节）的缓冲区大小。因此，每个已填充的缓冲区持续约0.0928秒的音频，这比创建数据所需的时间长得多（1〜6
ms）。因此，我知道我没有足够快地生产样品的问题。

我还应注意，在应用程序生命周期的前3秒内，它可以正常工作-
滑块的平滑扫描会在音频输出中产生平滑的扫描。此后，它开始变得非常震荡（声音每100Mhz仅变化一次），此后，它完全停止响应滑块输入。

我还修复了一个错误，但我认为它没有效果。AudioTrack.getMinBufferSize（）返回BYTES中最小的允许缓冲区大小，并且我使用此数字作为tick（）中缓冲区的长度-
现在我使用此数字的一半（每个样本2字节）。

Answer 1

我找到了！

事实证明，该问题与缓冲区或线程无关。

在最初的几秒钟内听起来不错，因为计算的角度相对较小。随着程序的运行以及角度的增大，Math.sin（_currentAngle）开始生成不可靠的值。

因此，我替换Math.sin()为FloatMath.sin()。

我也换了 _currentAngle = _currentAngle + _angleIncrement;

与

_currentAngle = ((_currentAngle + _angleIncrement) % (2.0f * (float) Math.PI));，因此角度总是<2 * PI。

奇迹般有效！非常感谢您的帮助，praetorian droid！