实时音频同步(第 1 部分)

实时同步技术错综复杂,它一直是一个令我着迷的课题。今天,我想与大家分享我构建一个系统的方法,这个系统可以在位于不同物理区域的设备之间实时同步音频。

试想一下,我们在一个家庭的多个房间里安装了多台设备。这些设备可以通过共享的 WiFi 网络以极低的延迟相互通信。或者,它们也可以通过其他类型的专用网络进行连接。在某些情况下,我们可能需要同步相距很远且仅通过互联网连接的设备。

实时音频同步(第 1 部分)

主要目标是实现尽可能高的同步精度,为用户提供无缝的音频体验。

其中一个重要因素是延迟补偿。我们的逻辑应该能够补偿可变延迟。这可能包括动态调整播放速度或预先缓冲音频数据,以确保平稳同步。

在构建一个使用通用存储解决方案在多台设备上同步播放音频的系统时,我们要充分利用存储容量充足且易于访问的优势。如果需要同步播放的音频文件已经上传到这个共用存储器中,那么每个设备都可以根据需要获取音频块,从而以最小的开销保持同步。

同步音频播放方法

情景: 我们的目标是在多台设备上同步播放存储在一个可访问的通用存储位置中的音频文件。所有设备都以合理的大小分块从这一共同来源读取文件。通信主要限于播放、暂停、跳转等控制事件。

关键同步事件

1. 暂停事件:

  • 挑战:当一台设备发出暂停命令时,将此事件传达给所有其他设备存在固有延迟。在 01:05 时发出的暂停事件可能在 01:06 时被另一台设备接收到,从而导致时间上的不同步。如果多播放和暂停几次,这一差距可能会继续扩大,导致完全不同步。
  • 解决方案: 将精确的时间戳作为有效载荷与暂停事件一起发送。这样可以确保所有设备在正确的时间点暂停,而不受延迟的影响。例如,如果在 t1 时发出暂停事件,并在 t2 时接收到该事件,那么设备应在时间戳 t1 时暂停,从而使所有设备精确对齐。

2. 播放事件:

  • 挑战:与暂停事件类似,接收播放命令的延迟也会导致设备长时间不同步。
  • 解决方案:考虑延迟时间,计算开始时间。假设 t1 是播放事件发出时的时间戳,t2 是接收到播放事件时的时间戳,t3 是音频暂停时的位置。播放应在 t2 – t1 + t3 时恢复。这样可以补偿延迟并确保同步。

3. 前跳/后跳

  • 挑战:跳转到新位置会带来与播放和暂停事件相同的延迟问题。
  • 解决方案:使用相同的基于时间戳的方法。当发出跳过事件时,在有效载荷中包含目标时间戳。每个设备都会根据该时间戳调整播放位置,确保所有设备保持同步。

4. 切换音轨

  • 挑战:切换音轨也会产生延迟,导致设备在不同时间开始播放。
  • 解决方案:包含音轨更改事件的时间戳。当设备接收到该事件时,它会通过考虑延迟来计算新轨道的正确开始时间,这与播放事件类似。

工作流程示例

1. 暂停事件:

  • 设备 A 在 t1 时发出暂停命令。
  • 设备 B 在 t2 时收到暂停命令。
  • 设备 B 在时间戳 t1 处暂停播放,确保同步。

2. 播放事件:

  • 设备 A 在 t1 时刻发出播放指令。
  • 设备 B 在 t2 时刻接收播放指令。
  • 假设 t3 是给定音频文件中所有设备在调用暂停事件时应该暂停的位置。
  • 设备 B 从 t2 – t1 + t3 开始恢复播放,补偿延迟。

3. 提前跳转:

  • 设备 A 发出跳至时间戳 t4 的指令。
  • 设备 B 收到跳过命令后,将其播放调整到 t4。

4. 切换音轨

  • 设备 A 在 t5 时切换到新轨道。
  • 设备 B 接收到换轨命令,并在 t5 启动新轨道。

设备之间的直接通信

现在,让我们深入探讨一下没有传统存储设备或需要使用实时流媒体的情况。这可能是由于一些限制因素造成的,例如处于封闭的专用网络中,没有外部访问权限,或者互联网连接不畅。在这种情况下,直接向其他设备传输音频就变得非常有利。很明显,在播放前预发送音频块具有显著优势。这种方法需要传输比播放所需更多的音频块。

1. 网络拓扑:

它在设备之间建立直接连接,创建各种网络拓扑结构,如点对点(P2P)、星形、网状或树形网络。设备之间通过网络直接通信,无需任何中介。这就通过建立直接连接实现了设备之间的高效通信,从而加快了传输速度。其次,它们具有灵活性,可根据具体要求选择不同的网络结构。

2. 消息队列

在这里,设备通过消息队列系统传输音频数据进行通信。每个设备都可以充当音频块的生产者和/或消费者。常见的消息队列系统包括 RabbitMQ、Apache Kafka 或 ZeroMQ 等更简单的替代方案。我们可以利用消息队列提供的内置实用程序来对数据包进行排序。

为了直接进入操作,我选择在 Google Cloud Platform的 VPC 环境中进行模拟。敬请期待第二部分,我将深入探讨其实施过程中错综复杂的技术问题。

作者:Rishi Desai
原文:https://medium.com/@rishindesai/real-time-audio-synchronization-part-1-672e01d8b2b3

本文来自作者投稿,版权归原作者所有。如需转载,请注明出处:https://www.nxrte.com/jishu/48859.html

(0)

相关推荐

  • 实时音频同步(第 2 部分)

    多设备音频实时同步是一项引人入胜的挑战,它涉及解决延迟问题和确保播放事件的精确定时。在本系列中,我们将深入探讨此类系统的复杂技术。在第 1 部分中,我们讨论了实现精确定时以确保无缝…

    2024年6月13日
  • 音视频学习–音画同步

    上周和新入职的测试小姐姐一起讨论一些问题时,被问“音画同步”是怎么回事儿,要怎么验证,巴拉巴拉解释了一通,在此也形成一个笔记,分享有需要的人。 音视频同步 音视频封装是将音频和视频…

    2023年9月5日
  • 从浅到深掌握音视频不同步问题!

    这几天在搞mp4的时候,看到的一篇对音视频不同步的好文章,在这里分享给大家! 音视频同步的基本概念与重要性: 1.1 音视频同步的定义与影响 音视频同步(Audio-Video S…

    2023年11月11日
  • 如何搞定棘手的音视频不同步问题!

    本文主要描述音视频同步原理,及常见的音视频同步方案,并以代码示例,展示如何以音频的播放时长为基准,将视频同步到音频上以实现视音频的同步播放。 音视频同步简单介绍 对于一个播放器,一…

    2023年4月27日
  • 音画同步测试方法的研究与实践

    导读:音视频通话中的音画同步问题一直是一个重要的挑战。传统的主观测试方法往往受到主观因素的影响,难以准确评估音画同步的质量。为了解决这个问题,针对业界已有的客观测试方法做了一定研究…

    2023年9月6日
  • Android ffmpeg音视频同步

    前言:在实现视频和音频的播放过程中,其中最大的问题是音频和视频之间的播放速度如果没有同步,视频按照解码的速度,以最快速度进行了上屏,那么很有可能会出现视频播放完后音频还在播放的情况…

    2023年2月18日

发表回复

登录后才能评论