这个想法是Phone A同时发送声音信号和蓝牙信号，Phone B将计算两个信号之间的延迟。
在实践中，我得到的结果不一致，延迟从 90 毫秒到 160 毫秒。我尝试尽可能优化两端。
在输出端：
一旦蓝牙和音频输出各有自己的线程，就会产生音调
蓝牙仅在 AudioTrack.write 之后输出，并且 AudioTrack 处于流模式，因此它
应该在写入完成之前开始输出。
在接收端：
再次两个单独的线程
系统时间在每个 AudioRecord.read 之前记录
采样规格：
44.1khz
读取整个缓冲区
使用 fft 一次采样 100 个样本
考虑到自初始 read() 以来转换了多少样本
您的方法在整个管道中基本上依赖于零延迟，这实际上是不可能的。您只是无法以那种准确度同步它。如果您可以将延迟降低到 5-6 毫秒，这可能是可能的，但在此之前您会用力敲击键盘。即便如此，也只能精确到1.5米左右。
考虑您收到的延迟的下限。在 90ms 内，声音可以传播30m 以上。这是市场上销售的蓝牙范围的最末端，甚至没有考虑到您可能处于非理想的传输条件。
这是一个讨论 Android 中低延迟音频的线程。TL; DR 是它很糟糕，但正在变得更好。使用最新的 API 和最近的设备，假设您运行一些手动调整的音频功能，您可能能够将其缩短到 30 毫秒左右。这里没有简单的 AudioTrack。即便如此，这仍然是一个很好的 10 米圆形错误概率。
编辑：
假设您可以同步设备的时钟，更好的方法是使用简单的 am/fm 调制或脉冲序列将时间戳嵌入到音频信号中。然后你可以在另一端解码它并知道它是什么时候发送的。您仍然必须处理延迟问题，但它很好地简化了整个事情。根本不需要蓝牙，因为它无论如何都不是一个真正可靠的时钟，因为它可以被认为有它自己的延迟问题。
这为您提供了一个很好的方法 http://netscale.cse.nd.edu/twiki/pub/Main/Projects/Analyze_the_frequency_and_strength_of_sound_in_Android.pdf
您必须创建一个具有一定幅度（以 dB 为单位）的 1 kHz 声音，并尝试测量到达其他设备的声音的幅度。从镇静剂中，您也许可以测量距离。
我记得：a0 = 20*log (4*pi*distance/lambda) 其中 a0 是镇静剂，而 lambda 是给定的（你可以从 1kHz 算起）但是在如此敏感的环境中，噪音可能会破坏整个事情，只是一个想法，如果我是你，我会怎么做。