说实话，我最初对“AroundSound”这个标题的第一反应是：又一个音频可视化 Demo，拖个滑块、转个圈，听个响就完事了。但真正动手做下来，发现完全不是这么回事。当我在浏览器里用 Web Audio API 把声音“钉”在三维空间中的某个坐标上，然后转动“头部”听它从正前方绕到左后方，那种感觉非常微妙——这不是简单的左右声道平衡，而是一种近乎物理性的空间感知。这个项目最后长成的样子，是一个完全跑在浏览器里的环绕声/空间音频沙盒：可以自由摆放声源、拖动声像、改变距离衰减、用鼠标旋转“耳朵”的方向，所有声场状态实时映射到 Canvas 极坐标上。整个过程没有借助任何音频引擎或游戏框架，全部基于 Web Audio API 原生节点搭建。

这篇文章就从 AroundSound 的完整实现出发，聊清楚几个事：环绕声在 Web 端到底是怎么“骗”过耳朵的，整套音频路由架构怎么搭，PannerNode 的每个参数在听感上到底动了什么手脚，以及我在移动端、自动播放策略、性能调优上踩过的那些坑。适合三类人看：想做沉浸式音频或者播客音效的前端开发者，对空间音频原理感兴趣的声音设计爱好者，以及想用纯前端给游戏或交互页面加“方位感”的创意程序员。

1. 为什么用浏览器做环绕声：Web Audio API 的独特优势

1.1 从“听个响”到“指哪打哪”

过去要在浏览器里做环绕声，常规思路是塞一个多声道的音频文件，比如 5.1 声道的 FLAC，然后给用户一个音量平衡面板。这种做法本质上是在“播放”预先编码好的声道，而不是在“计算”声场。AroundSound 从头到尾没有用任何多声道素材，所有环绕效果都是实时算出来的：一个普通立体声声音文件，被我放在三维空间的某个坐标上，系统根据它相对于“耳朵”的方向、距离、角度，实时计算出一对立体声输出。你听到的“左边后方有声音”这种方位感，不是素材里编码的，而是浏览器每帧算完送给你的。

这就带来了一个关键区别：声源和听者的位置关系是动态的。我可以把声源拖到屏幕任何一个地方，甚至可以自转——听感会连续跟着变，而不是在几个固定声道之间硬切。Web Audio API 的 PannerNode 就是干这个活的，它本质上是一个实时空间化处理器，输入一路声音，根据位置参数计算输出立体声。

1.2 这个项目适合谁读，读完能收获什么

如果你做过 Web 音频开发，大概率用过 AudioBufferSourceNode 去播放一个文件，可能也接触过 GainNode 做音量控制。但 PannerNode 在绝大多数项目里用得并不深，因为大部分人只把它当成一个带 3D 效果的音量节点。AroundSound 的价值在于，它把所有跟空间有关的节点串成了一个完整的体系：声源姿态、监听器朝向、距离模型、方向锥、可视化坐标，还有和鼠标交互的联动逻辑。

读完这篇文章，你会得到一套可以直接复用的空间音频实现方案：我的音频节点拓扑、PannerNode 各参数的调参经验、Canvas 坐标到声场坐标的换算思路、移动端兼容的踩坑记录。如果你想把一个普通网页变成一个小型声音实验室，这些内容可以省掉你大量的试错时间。

2. 环绕声的“骗术”：增益、滤波与距离衰减

2.1 实现空间感的底层逻辑

很多人对环绕声有误解，以为必须有多声道音箱系统或者 7.1 声道的音源。其实人耳判断声音方向，依赖的不是声道数量，而是三个核心线索：

• 音量差：声音从左边来，左耳听到的音量比右耳大。
• 时间差/相位差：声音到达左耳比右耳早那么零点几毫秒。
• 频谱滤波：头部、耳廓会对来自不同方向的声音产生不同的滤波效果，尤其是高频部分。

有了这三个线索，大脑就能大致还原声源的方向。Web Audio API 的 PannerNode 正是模拟了这套机制。它有两种工作模式，对应两条技术路线：

模式	原理	听感特点	适用场景
等功率增益平移（equalpower）	按声像角度在两声道间分配增益	左右方位清晰，但前后、上下方位几乎没有差异	传统音乐混音中的声像移动
HRTF（基于头部相关传输函数）	用一组与方向相关的滤波器模拟头部、耳廓对声音的影响	前后、上下方位感明显，有“头中效应”风险	游戏、VR、环绕声实验

AroundSound 默认使用 HRTF 模式，因为它能提供真正意义上的“环绕”感，而不仅仅是左右平衡。代价是计算量更大，在低端设备上更容易出现毛刺。后面我会详细讲不同模式下的实际听感差异。

2.2 PannerNode 参数究竟在控制什么

PannerNode 初始化的一个典型配置如下：

const panner = audioContext.createPanner();
panner.panningModel = 'HRTF';
panner.distanceModel = 'inverse';
panner.refDistance = 1;
panner.rolloffFactor = 1;
panner.coneInnerAngle = 360;
panner.coneOuterAngle = 0;
panner.coneOuterGain = 0;
panner.setPosition(x, y, z);
panner.setOrientation(x, y, z);

这里每个参数都在改变听感，而且它们之间是有相互作用的，理解这一点很重要：

panningModel 决定方位感的“质感”。HRTF 模式下，声音不是简单地从左到右，而是带有明显的空间包裹感，闭上眼睛能“看到”声源大概在你哪一边。但它也有个副作用：部分素材在耳朵正后方时，会出现“前后混淆”（声音听起来似乎从前面来）。等功率模式则干净利落，但只能表达左右，不能表达上下前后，更没有“从后脑勺传来”的感觉。

distanceModel 决定声音随距离衰减的方式。 inverse 模拟现实世界中声压随距离衰减的规律，贴近真实的听感； linear 在近距离范围内衰减更平缓； exponential 衰减最快，适合做某些特殊效果。AroundSound 里我用的是 inverse ，它最接近我们日常听声音的经验。

refDistance 和 rolloffFactor 是衰减曲线的两个旋钮。 refDistance 是参考距离，在这个距离上音量刚好是原始音量；小于它音量反而可能超过原始值。 rolloffFactor 控制衰减斜率，1 是自然衰减，大于 1 会让距离变化更敏感。实际调参时，我建议先固定 refDistance = 1 ，然后慢慢调节 rolloffFactor ，直到你拖拽声源时能明显听到“靠近变大、远离变小”的连续变化，而不是突然被切了一刀。

coneInnerAngle 、 coneOuterAngle 和 coneOuterGain 这三个参数负责声源的指向性，可以理解为“喇叭的朝向”。默认 360 度意味着声源是全向发声的，任何方向听起来音量一样。如果你把内角设为 120、外角设 360、外圈增益设 0.1，那就模拟了一个指向性很强的喇叭：正对喇叭的方向声音响亮，绕到侧面或背后声音迅速变小。AroundSound 的场景预设里，我专门做了一个“舞台喇叭”模式，让用户拖动声源时感受指向性的差异。

注意：PannerNode 的 cone 参数在 HRTF 模式下有时会和 HRTF 本身的滤波效果叠加，导致某些角度听感过渡不够自然。实测中发现，模拟全向声源（内角 360）时最好把 cone 相关参数设为默认值，不要额外做衰减。

3. AroundSound 整体架构与核心模块拆分

3.1 节点拓扑：一条清晰的音频流水线

AroundSound 的音频图结构非常简单，但每一层都有明确的职责：

AudioBufferSourceNode -> PannerNode -> GainNode -> AudioContext.destination

简单说就是：声源先经过空间化处理，再进总线控制总音量，最后输出到扬声器。所有声源的 PannerNode 都并联在同一个 GainNode 上，这个 GainNode 就是 AroundSound 的“总音量推子”。这样做的好处是——当你需要做整体淡出、静音、或者接一个 Master 压缩器时，只需要在总线上动手，不用去遍历所有声源。

用代码来表达这个路由过程：

// 每个声源独立创建，但它们共享同一个 audioContext 和 masterGain
function createSpatialSource(buffer, position) {
  const source = audioContext.createBufferSource();
  source.buffer = buffer;
  source.loop = true;

  const panner = audioContext.createPanner();
  panner.panningModel = 'HRTF';
  panner.distanceModel = 'inverse';
  panner.refDistance = 1;
  panner.rolloffFactor = 1;
  panner.setPosition(position.x, position.y, 0);

  const gain = audioContext.createGain();
  gain.gain.value = 0.8;

  source.connect(panner);
  panner.connect(gain);
  gain.connect(masterGain);

  return { source, panner, gain };
}

这个结构看起来平淡无奇，但它暗含了一个重要的事：声源的音量控制被拆成了两层——PannerNode 自己会因距离衰减改变输出音量， gain 节点负责声源的“原始音量”。这样当你调大原始音量时，距离衰减的关系仍然成立，不会有“声音大到无视距离”的失真感。

3.2 声源管理与音频资源释放

AudioBufferSourceNode 有一个容易忽略的特性：它是 一次性节点 。一旦 stop() 被调用，这个节点就不能再次 start() ，同一个节点不能反复使用。但 AudioBuffer 是可以复用的——它是纯数据，不绑定播放状态。

所以在 AroundSound 里，我维护了一个声源对象池，每个声源对象保存了 buffer 、 source 、 panner 、 gain 的引用。当需要停止一个声源时，先调 source.stop() ，再断开所有连接，最后把 source 置空，但保留 buffer 和 panner 的引用。这样下次需要重新播放时，只要创建一个新的 AudioBufferSourceNode ，把旧的 buffer 赋给它，重新连接即可：

function playBuffer(buffer, panner) {
  const source = audioContext.createBufferSource();
  source.buffer = buffer;
  source.loop = true;
  source.connect(panner);
  source.start();
  return source;
}

为什么中间要断连再重连？因为 Web Audio 的节点图是一个有向图，一个节点可以同时连接到多个下游节点，但如果你不手动断开，旧节点会一直挂在图里，当音频上下文在持续运行时，这些悬挂节点会悄悄占用资源。长时间往返切换场景后，页面会越来越卡，这就是内存泄漏的一个典型来源。

3.3 监听器与头部旋转的坐标转换

环绕声不是只设置声源位置就行，还有一个隐藏要素是“耳朵”的位置和朝向—— AudioListener 。每个 AudioContext 自带一个 listener ，默认在原点。如果声源固定、不移动监听器，那听到的方位感永远是相对原点而言的。

AroundSound 实现“头部旋转”的方式很直接：监听器位置固定在原点，但朝向（orientation）跟随鼠标移动。以屏幕为世界坐标系，鼠标横坐标对应航向角 yaw，纵坐标对应俯仰角 pitch，然后换算成 setOrientation 需要的方向向量：

function updateListenerFromMouse(clientX, clientY, canvasWidth, canvasHeight) {
  const yaw = (clientX / canvasWidth) * Math.PI * 2;
  const pitch = (clientY / canvasHeight) * Math.PI - Math.PI / 2;

  // 将角度转为三维方向向量：前方、上方
  const forward = new Float32Array([
    Math.sin(yaw) * Math.cos(pitch),
    Math.sin(pitch),
    Math.cos(yaw) * Math.cos(pitch)
  ]);
  const up = new Float32Array([0, 1, 0]);

  audioContext.listener.forwardX.value = forward[0];
  audioContext.listener.forwardY.value = forward[1];
  audioContext.listener.forwardZ.value = forward[2];
  audioContext.listener.upX.value = up[0];
  audioContext.listener.upY.value = up[1];
  audioContext.listener.upZ.value = up[2];
}

听者位置不动、只转头部，这种交互模型非常符合直觉：你不需要理解三维坐标，只需左右移动鼠标，声音就会跟着头部转动，仿佛你的耳朵变成了一个可旋转的麦克风阵列。实际体验时，最难的是把"屏幕坐标"和"世界坐标"统一起来。如果声源位置用的是世界坐标，监听器朝向用的是屏幕坐标映射，两者不统一就会出现“越转越晕”的错位感。我的做法是把屏幕坐标直接当作世界坐标的 X/Y 值，Z 轴留作距离维度，从 Canvas 到声场不需要额外的矩阵变换，逻辑简单且不容易出错。

3.4 Canvas 可视化：把方位画出来

可视化是 AroundSound 的灵魂之一。没有可视化，你只能靠耳朵判断方位，一旦有点混淆就不知道声音到底在哪。所以在 Canvas 上，我用极坐标的方式把整个声场画了出来：中心是监听器，周围一圈刻度线是方位角，每个声源显示为一个光圈，光圈的大小代表音量，颜色深浅代表距离。

坐标转换的代码其实是整个项目里最简单的部分：

function worldToCanvas(worldX, worldY, centerX, centerY, scale) {
  return {
    x: centerX + worldX * scale,
    y: centerY - worldY * scale
  };
}

关键在渲染策略。声场是连续的、变化的，但我没有用全屏逐帧重绘（那样 CPU 占用会很高），而是只更新声源图标和轨迹线。轨迹线是额外的亮点：每帧记录声源的极坐标位置，画成一条半透明的尾巴。这样你能直观看到声源是从左边绕到后方的，还是直接瞬移过去的。视觉效果叠加听觉反馈，整个空间感就立体了。

4. 关键交互与场景扩展：从拖拽、滚轮到自动环绕

4.1 在画布上添加声源与拖拽移动

AroundSound 的第一个交互是"点击画布添加声源"：用户点击一个位置，就在那个位置生成一个声源并播放。这个实现很简单，canvas 的 click 事件里取坐标，然后调 createSpatialSource 。

拖拽移动则是核心。我给每个声源画了可点击的热区，拖拽时实时更新 PannerNode 的坐标。这里有个非常容易忽略的细节：不要把 setPosition 和 requestAnimationFrame 绑在一起。每次鼠标移动事件里可以直接调用 setPosition ，Web Audio API 本身会对参数变化做插值平滑，不需要你每帧去设置坐标。如果每帧设置，反而可能因为更新频率太高，在部分浏览器上产生明显的 zipper noise（阶梯噪声）。我实测下来，鼠标事件里直接调 setPosition ，听感是最顺滑的。

4.2 滚轮调距离与距离衰减的调参心得

滚轮控制的是声源在 Z 轴上的位置，也就是和听者的距离。在 Canvas 上，我没有用三维透视，而是用"光圈大小"来表达距离：声源越近光圈越大，越远光圈越小。这样用户能同时从视觉和听觉两个维度感知距离变化。

距离衰减的调参是这整个项目里最费耳朵的部分。 rolloffFactor 调大了，声源从远到近的音量变化非常剧烈，像在坐过山车；调小了，又几乎感觉不到远近差异。我最终的方案是做了一套分段映射，而不是让 rolloffFactor 暴力地承担所有工作：

// 用对数映射把滚轮值转换成 Z 轴距离
const distance = Math.pow(10, normalizedScroll * 2) - 1;
panner.setPosition(x, y, -distance);

这样做的意义在于：对数映射让近距离范围的精度更高，远距离的范围更开阔，听感上更接近真实世界“近处变化明显、远处变化迟钝”的体验。如果直接用线性映射，你会发现滚轮前一段距离变化几乎没感觉，后一段又瞬间变得太远。

4.3 程序化合成音色与预设场景切换

AroundSound 里大部分音色不是加载音频文件，而是用 OscillatorNode 等节点实时合成的。这样有两大好处：一是部署时不需要带素材文件，项目随时可以跑起来；二是合成音色和 PannerNode 配合时更容易控制参数，不需要担心素材本身的声像信息干扰空间感。

举个实际的例子，我做了一个"雷达脉冲"预设，用 OscillatorNode 产生一个正弦波扫频，再连接到 PannerNode：

function createPulseTone(panner) {
  const osc = audioContext.createOscillator();
  const freq = audioContext.createBiquadFilter();
  freq.type = 'bandpass';
  freq.Q.value = 8;

  osc.type = 'sine';
  osc.frequency.value = 800;

  // LFO 控制频率，做出"叮~叮~"的脉冲感
  const lfo = audioContext.createOscillator();
  const lfoGain = audioContext.createGain();
  lfo.frequency.value = 1.5;
  lfoGain.gain.value = 400;
  lfo.connect(lfoGain);
  lfoGain.connect(osc.frequency);

  osc.connect(freq);
  freq.connect(panner);

  osc.start();
  lfo.start();
  return { osc, lfo };
}

场景切换就是把这些程序化音色排列组合。我有"风声雨声"、"星际"、"城市噪音"等预设，每个预设定义了若干声源的类型、初始位置和运动模式。切换场景时，不是简单 stop 所有声源，而是做了一个淡出淡入的过渡：先降低主 GainNode 的音量到 0，然后停止旧节点，创建新节点，再恢复主增益。这样切换过程中不会有刺耳的爆音。

4.4 给声源加"旋转"效果

这是 AroundSound 里最有观赏性的功能：选中一个声源，点击“旋转模式”，它就会围绕听者做圆周运动。这是典型的“动态空间化”，用来检验 PannerNode 的方位变化是否跟手。

实现思路很直接：在 requestAnimationFrame 循环里更新角度，并同步到 PannerNode 的坐标：

function startOrbit(sourceData, radius, speed) {
  const startTime = performance.now();
  const orbit = (now) => {
    const elapsed = (now - startTime) / 1000;
    const angle = elapsed * speed;
    const x = Math.cos(angle) * radius;
    const y = Math.sin(angle) * radius * 0.5; // 扁椭圆轨道

    sourceData.panner.setPosition(x, y, 0);
    sourceData.currentAngle = angle;

    if (sourceData.orbiting) {
      requestAnimationFrame(orbit);
    }
  };
  requestAnimationFrame(orbit);
}

注意我在 Y 轴上乘了 0.5，把圆形轨道变成了扁椭圆。这是为了模拟现实世界的听感习惯：声音在水平面上的环绕最符合直觉，如果 Z 轴高度也参与大幅变化，很容易产生“声音在天上飞”的混乱感。椭圆轨道在保证环绕感的同时，让声源的垂直变化比较克制。

5. 实测与踩坑记录：移动端、自动播放策略与性能毛刺

5.1 iOS 与 Safari 的兼容性问题

我把 AroundSound 部署到测试环境后，第一个让我头疼的不是 CPU 占用，而是 iPhone 上完全没声音。原因很典型：iOS 上的 Web Audio 需要一个用户手势才能启动 AudioContext ，而且早期的 iOS 版本压根不显示 AudioContext 对象，需要加前缀 webkitAudioContext 。

用兼容代码可以解决大部分情况：

const AudioContext = window.AudioContext || window.webkitAudioContext;
const audioContext = new AudioContext();

但这里还有一个时序问题：必须是用户点击事件触发的 audioContext.resume() 才有效，而在 resume() 之前如果调用了 source.start() ，声音可能不会播放，状态还卡在 suspended 。所以我做了一套初始化流程：页面加载时先创建 AudioContext ，但所有声源都处于"待命"状态，等用户第一次点击画布时，先 await audioContext.resume() ，再开始创建声源。这个“先恢复再播”的顺序不能颠倒，否则在 iOS 上会静音。

5.2 浏览器的自动播放策略与 AudioContext.resume()

自动播放策略不只在 iOS 上有，Chrome、Edge 等桌面浏览器同样限制没有用户手势的音频播放。AroundSound 预加载音频文件的方式是 fetch + decodeAudioData ，这个过程本身不需要音频上下文被恢复，但播放必须等手势。

这里有个容易踩的坑： decodeAudioData 是异步的，而且是耗时的。如果你在用户 click 事件里同步去 decode 一个大文件，界面会卡顿，而且可能错过浏览器允许音频播放的时机窗口。我的做法是在页面 load 之后就开始异步预解码所有素材，用户点击时只需从缓存里取 buffer，不需要临时等待。

另外， resume() 返回的是一个 Promise，在某些浏览器里如果音频上下文已经处于 running 状态，它也会正常 resolve。所以不用过度担心“调用太多次”的问题，只要每次都 await 一下，后续逻辑就安全了。

5.3 可视化帧率与多声源性能优化

AroundSound 的性能瓶颈不在音频，而在可视化。最初版本我用 Canvas 2D 绘制每一个声源时，都调用 arc() 和 stroke() 来画一个圆加上很多细节，同时实时绘制轨迹线。当声源数量超过 8 个时，帧率掉到 30 帧以下，整个交互变得卡顿。

优化方案分三步：

• 第一，轨迹点降采样。不再每帧压入一个点，而是只在声源角度或距离变化超过阈值时才记录一个轨迹点。这样轨迹线依然连续，但点数能减少一半以上。
• 第二，用离屏 Canvas 缓存静态元素。刻度盘、背景网格这些不变的元素单独画到一个离屏 Canvas 上，每帧只需要 drawImage 贴一次背景，不需要重新绘制网格。
• 第三，控制阴影等重型特效。Canvas 的 shadowBlur 非常消耗性能，所以只有选中声源才开启阴影，普通声源用简单的圆形加描边代替。

经过这三步优化，在普通笔记本电脑上，10 个声源同时运行时主线程负载明显下降，音频不受影响。音频和可视化在同一个线程，但不代表音频会被可视化拖牺牲——Web Audio API 的音频处理是独立线程进行的，可视化卡顿不会导致声音中断，但如果你在主线程上做太多重工作，音频引擎的调度会受影响，出现细微的爆音。所以可视化的性能优化依然重要。

5.4 前后混淆问题与听感校准

HRTF 模式有一个众所周知的问题：前后混淆。有时候声音明明在正后方，你听起来却像在正前方。为了减小这个问题，我在 AroundSound 里做了一层额外的“前后差异提示”，在正后方（大约 160° 到 200° 范围内）稍微降低一点音量，并给声音加一个极轻的低通滤波，模拟声音被头部遮挡后的自然反应：

const angle = calculateAngle(source, listener);
let gainReduction = 1;
let lowpassAmount = 0;

if (angle > 150 && angle < 210) {
  const overlap = 1 - Math.abs(angle - 180) / 30;
  gainReduction = 1 - overlap * 0.15;
  lowpassAmount = overlap * 2000; // Hz
}

panner.positionX.value = x * gainReduction;
// 对滤波器频率做平滑变化
freqFilter.frequency.setTargetAtTime(20000 - lowpassAmount, audioContext.currentTime, 0.1);

这样做不是要让声音失去 3D 感，而是通过微小的音色差异给大脑额外的前后判别线索。实测下来，前后混淆的现象改善不少，代价是正后方的声音会略微发闷，但听感上反而更自然。这段代码中 setTargetAtTime 比直接赋值更平滑，不会出现滤波器频率突变产生的“啪”声。

6. 还能怎么扩展：从浏览器 Demo 到更完整的空间音频工具

6.1 与 Three.js 的 PositionalAudio 打通

如果你在游戏或 WebXR 项目里用过 Three.js 的 PositionalAudio ，你可能会好奇它为什么能自动跟随 3D 对象。拆开看，Three.js 的 PositionalAudio 底层就是 PannerNode ，它的 positionX 、 positionY 、 positionZ 属性在内部被绑定到三维物体的世界坐标。所以你可以把 AroundSound 的节点管理思路直接迁移到 Three.js 项目里。

我的建议是做一个简单封装：在 Three.js 里维护一个 SoundSource 类，内部封装 AudioBufferSourceNode + PannerNode ，然后暴露 attachTo(object3D) 方法，在渲染循环里同步坐标：

update() {
  this.object3D.getWorldPosition(this.worldPos);
  this.panner.positionX.value = this.worldPos.x;
  this.panner.positionY.value = this.worldPos.y;
  this.panner.positionZ.value = this.worldPos.z;
}

这样你在游戏里移动每个物体、转动摄像机时，声音会自动跟着动，不需要手动管理任何音频节点的位置。AroundSound 里的所有调参经验—— refDistance 、 rolloffFactor 、 cone 设置——在 Three.js 里直接复用，完全不需要改。

6.2 录制与导出：离线渲染方案

目前 AroundSound 是实时播放的，没有录制导出的能力。如果你想把一段空间音频导出成文件，思路要换一下：不能录系统输出，而是用 OfflineAudioContext 做离线渲染。 OfflineAudioContext 不连接扬声器，它可以在极短的时间内（甚至快于实时）渲染出音频数据，然后导出为 WAV 文件。

核心步骤和实时播放几乎一样：

• 创建一个 OfflineAudioContext 实例，指定声道数和采样率。
• 在这个上下文里重放所有声源、PannerNode、增益节点。
• 调用 startRendering() ，得到 AudioBuffer 。
• 把 AudioBuffer 编码成 WAV，然后通过 blob 下载。

这样你就把“浏览器里的环绕声”变成了一个可以编辑的音频文件，能拿进 DAW 里继续混音或加效果。需要注意的是：离线渲染时，所有音频节点必须在渲染开始前创建并连接好，否则可能被自动跳过。

6.3 多人协作与网络音频的想象空间

如果你把 AroundSound 的监听器状态抽取出来——头部朝向、世界位置——然后通过网络同步这些参数，就能做成一个“异位面听音”的工具：两个人分别在不同页面，但共享同一组声源，各自旋转头部时听到的方位略有不同。这听起来像是 3D 语音聊天室的概念，但技术上其实就是把 listener 的参数通过网络广播出去。

WebRTC 的 DataChannel 或者 WebSocket 都能胜任这种同步需求。声源位置变化非常轻量，一段 JSON 就能描述，完全不用担心带宽问题。更激进的做法是传输 OSC 消息，让 AroundSound 接收来自手机陀螺仪或 MIDI 控制器的数据，把头部追踪变成真实的物理设备，那就是真正的沉浸式音频应用了。

写在最后的实操建议

做 AroundSound 这个项目，给我最大的感受是：空间音频最难的从来不是数学，而是从参数到听感的反复校准。PannerNode 的每个参数都有明确含义，但它们在真实素材上的表现，需要你戴上耳机、关掉可视化界面，反复移动声源去听。我最终调试出一套比较满意的默认参数组合，但换一个声音素材、换一副耳机，听感就会有差异。所以做这一类项目，务必留一个“参数面板”，方便随时调整。

最后分享一个我实际使用中的小技巧：在开发空间音频功能时，建议先只用 单声源单场景 调试，确认方位感、距离衰减、前后辨析都符合预期后，再逐步叠加声源。多声源混在一起时，任何方位上的偏差都会被其他声源掩盖，你很难判断是哪一环出了问题。AroundSound 能做到现在这个状态，很大程度上就是因为我把这个“先单后多”的原则贯彻到了整个调试过程中。