想法是电话A同时发送声音信号和蓝牙信号，电话B将计算两个信号之间的延迟。Android两台设备之间使用声音获取距离
实际上，我得到的结果不一致，延迟时间为90ms-160ms。 我试着尽可能地优化两端。
在输出端：生成一次
音 蓝牙和音频输出每个人都有自己的线程
蓝牙只输出后AudioTrack.write和AudioTrack是流模式，因此
应该开始输出之前写的甚至完成。
在接收端：
再次两个独立线程
系统时间被记录每个AudioRecord.read
采样规格之前：
44.1kHz的
阅读整个缓冲区
取样100个样本在时间使用fft
考虑到自初始读取以来已转化了多少个样品（）
Y我们的方法在整个流程中基本上都是零延迟，这是现实中不可能的。你无法用这种准确度来同步它。如果你可以将延迟降低到5-6ms，这可能是可能的，但在这种情况发生之前，你会将头撞到键盘上。即使那样，它也只能精确到1.5米左右。
考虑您收到延迟的低端。在90ms内，声音可以传播slightly over 30m。这就是蓝牙系列产品的末端，甚至没有考虑到你可能处于非理想的传输条件。
Here's a thread讨论Android中的低延迟音频。 TL; DR是它吸引人，但越来越好。使用最新的API和最新的设备，假设您运行一些手动调节的音频功能，您可以将或降到30ms左右。这里没有简单的AudioTrack。即使如此，这仍然是一个很好的10米圆形错误概率。
编辑：
一种更好的方法，假定可以同步设备的时钟，将嵌入的时间戳到音频信号中，使用简单的AM/FM调制或脉冲串。然后你可以在另一端解码，并知道它何时发送。你仍然需要处理延迟问题，但它很好地简化了整个事情。根本没有必要使用蓝牙，因为它本身并不是一个可靠的时钟，因为它可以被视为有自己的延迟问题。
感谢您的回复 声音在不停地录音，我只定时录制44-48ms的声音记录2048应该是非常接近46ms的样本。 fft需要0-1ms。我没有看到90毫秒延迟来自何处。 我目前正在通过声音发送比特，所以我可以发送时间戳，但我想避免同步时钟。如果蓝牙硬件/开销太慢，但速度非常快，我认为这种方法是必要的。 – user624056 2013-03-04 22:56:08
代码表示“播放”和声音从发言者身体出来之间需要多长时间？麦克风侧也一样。这是大多数音频应用中最大的延迟来源之一，并且由于它通常不是很一致，所以很难弥补。事实上，如果您不确定这些样本是否在手机上，您在约46ms内记录2048个样本并不意味着太多。任何方法都必须与之战斗，但音频延迟在Android上非常糟糕。 – Geobits 2013-03-04 23:00:39
使用setPlaybackPositionUpdateListener在函数被调用之前，我得到约14ms的延迟。除此功能外，我无法测量延迟。 – user624056 2013-03-05 01:16:02
你必须创建一些振幅（度量单位为dB）的1 kHz的声音和尝试测量声音的幅度到达其他设备。从镇静剂你可能能够测量距离。
我记得：a0 = 20 * log（4 * pi *距离/ lambda）其中a0是镇静和给出的lambda（可以从1kHz算起） 但是在这样敏感的环境中，噪音可能会破坏整个事情，只是一个想法，如果我是你，我会怎么做。
我认为这会和使用蓝牙信号强度一样不准确。 – user624056 2013-03-04 22:58:36
也许是的。但是你不必担心等待时间，因为你只需要不断地发出1kHz频率的声音并测量一段时间的镇静。平均值可能是一个好主意。 – 2013-03-04 23:57:30
如果您澄清并扩展您的问题，您可能会得到更好的答复。很难说出你究竟在问什么。 – FoamyGuy 2013-03-04 22:31:25
声音以331米/ 1000毫米或3.31米/ 10毫米的速度传播。是什么让你觉得你可以用商业设备来到达蓝牙信号和音频信号？ – 2013-03-04 22:42:08
事实上，这个商业设备具有1.4GHz的工作频率，并且在光行进1英尺之前将通过4个cpu周期。周期不等于命令，但我的定时声音延迟非常缓慢（每英尺1ms）〜1400000 cpu周期 – user624056 2013-03-04 23:05:16