其思想是电话A同时发送声音信号和蓝牙信号，电话B将计算两个信号之间的延迟。
实际上，我得到的结果与90ms-160ms之间的延迟不一致。
我尽量优化两端。
在输出端：
音调生成一次
蓝牙和音频输出都有自己的线程
蓝牙只在audiotrack.write和audiotrack处于流模式后输出，因此它应该在写入完成之前开始输出。
在接收端：
又是两条分开的线
系统时间记录在每次录音之前。
取样规格：
44.1kHz
读取整个缓冲区
使用fft一次采样100个样本
考虑自初始读取（）以来转换的样本数
最佳答案
您的方法依赖于整个管道的基本零延迟，这实际上是不可能的。你就是不能把它和那种精确程度同步。如果你能把延迟降到5-6毫秒，这可能是有可能的，但在那之前你会把脑袋撞到键盘上。即便如此，它的精度也只有1.5米左右。
考虑一下你收到的延迟的下限。在90毫秒内，声音可以传播slightly over 30m。这是市场上蓝牙系列的最末端，甚至没有考虑到您可能处于非理想的传输条件。
Here's a thread讨论android中的低延迟音频。医生认为这很糟糕，但正在好转。有了最新的api和最新的设备，您可能可以将其缩短到30ms左右，前提是您运行了一些手动调谐的音频功能。这里没有简单的音轨。即使如此，这仍然是一个很好的10米圆误差概率。
编辑：
一个更好的方法，假设你可以同步设备的时钟，将时间戳嵌入音频信号，使用简单的AM/FM调制或脉冲序列。然后你可以在另一端解码，知道它是什么时候发送的。您仍然需要处理延迟问题，但它很好地简化了整个过程。根本不需要蓝牙，因为它实际上不是一个可靠的时钟，因为它可以被认为有自己的延迟问题。