如何在不可靠的网络上同步媒体播放? [英] How to synchronize media playback over an unreliable network?

问题描述

我希望我可以在一台计算机上播放音乐或视频，并让另一台计算机同步播放同一媒体.在这种情况下，我可以同时听到两个计算机的扬声器，而且听起来并不有趣.

我想通过Wi-Fi进行此操作，这有点不可靠.

从算法上讲，解决此问题的最佳方法是什么?

修改1

是两台计算机播放"相同的媒体，还是一台播放"该媒体并将其流式传输到另一台，对我来说都没有关系.

我确定这是一个棘手的问题，因为我曾经看过Wi-Fi扬声器的演示.那是5年前，所以我认为今天该技术应该使它变得更容易.

解决方案

(我本人正在寻找可以完成此任务的应用程序，希望当我偶然遇到此问题时，我不必自己写一个.)

概述

您引入了一些缓冲区延迟，并使用网络时间同步协议来对齐流.也就是说，您将流分成多个数据包，并为每个数据包加上在时间T稍后播放"的时间戳，其中T例如在将来为50-100ms(如果网络故障，则更多).您将本地网络上的数据包发送(或多播)给合唱团中的所有计算机.由于应用程序时钟已同步，因此计算机将同时播放所有声音.

请注意，可能还需要将其他因素(例如OS/驱动程序/声卡延迟)纳入时间同步协议中.如果您不太清楚，则同步协议可能就像一台计算机每秒发出哔哔声一样简单，而且您还要敲打另一台计算机上的按键.这样做的优点是可以考虑OS/驱动程序/声卡层上的任何其他延迟源，但是缺点是如果时钟变得不同步，则需要手动干预.

---

混合手动网络同步

在不进行持续手动干预的情况下解决其他延迟源的一种方法是将这种方法与标准的网络时钟同步协议相结合；第一次在新计算机上运行协议:

1. 通过手动节拍式干预使机器同步
2. 使用网络时钟同步协议同步计算机
3. 对于合唱中的每台机器，取两个同步的差异；这是每台计算机的OS/驱动程序/声卡延迟，它们分别跟踪

现在，只要网络主干发生变化，所有要做的就是使用网络时钟同步协议(#2)重新同步，并减去OS/驱动程序/声卡延迟，从而避免了手动干预(除非您更改操作系统/驱动程序/声卡.

---

模仿自然的萤火虫同步

如果您在安静的房间中进行此操作，并且所有机器都配有麦克风，则甚至不需要手动干预(#1)，因为您可以使它们全部遵循萤火虫式"的同步算法.自然界中的许多萤火虫都会齐齐眨眼. http://tinkerlog.com/2007/05/11/synchronizing-fireflies/描述了这些萤火虫使用的算法:如果萤火虫收到邻居萤火虫的闪光，它会更早地闪烁."闪烁表示发出哔哔声或嗡嗡声(通过声卡，而不是主板压电蜂鸣器！)，而看到则相当于通过麦克风收听.

由于声音的速度，在很大的房间距离上这可能会有些尴尬，但我怀疑这将是一个问题(如果这样的话，会降低蜂鸣率).

I wish I could play music or video on one computer, and have a second computer playing the same media, synchronized. As in, I can hear both computers' speakers at the same time, and it doesn't sound funny.

I want to do this over Wi-Fi, which is slightly unreliable.

Algorithmically, what's the best approach to this problem?

EDIT 1

Whether both computers "play" the same media, or one "plays" the media and streams it to the other, doesn't matter to me.

I am certain this is a tractable problem because I once saw a demo of Wi-Fi speakers. That was 5+ years ago, so I'm figure the technology should make it easier today.

解决方案

(I myself was looking for an application which did this, hoping I wouldn't have to write one myself, when I stumbled upon this question.)

overview

You introduce a bit of buffer latency and use a network time-synchronization protocol to align the streams. That is, you split the stream up into packets, and timestamp each packet with "play later at time T", where T is for example 50-100ms in the future (or more if the network is glitchy). You send (or multicast) the packets on the local network, to all computers in the chorus. The computers will all play the sound at the same time because the application clock is synced.

Note that there may be other factors like OS/driver/soundcard latency which may have to be factored into the time-synchronization protocol. If you are not too discerning, the synchronization protocol may be as simple as one computer beeping every second -- plus you hitting a key on the other computer in beat. This has the advantage of accounting for any other source of lag at the OS/driver/soundcard layers, but has the disadvantage that manual intervention is needed if the clocks become desynchronized.

---

hybrid manual-network sync

One way to account for other sources of latency, without constant manual intervention, is to combine this approach with a standard network-clock synchronization protocol; the first time you run the protocol on new machines:

1. synchronize the machines with manual beat-style intervention
2. synchronize the machines with a network-clock sync protocol
3. for each machine in the chorus, take the difference of the two synchronizations; this is the OS/driver/soundcard latency of each machine, which they each keep track of

Now whenever the network backbone changes, all one needs to do is resync using the network-clock sync protocol (#2), and subtract out the OS/driver/soundcard latencies, obviating the need for manual intervention (unless you change the OS/drivers/soundcards).

---

nature-mimicking firefly sync

If you are doing this in a quiet room and all machines have microphones, you do not even need manual intervention (#1), because you can have them all follow a "firefly-style" synchronizing algorithm. Many species of fireflies in nature will all blink in unison. http://tinkerlog.com/2007/05/11/synchronizing-fireflies/ describes the algorithm these fireflies use: "If a firefly receives a flash of a neighbour firefly, it flashes slightly earlier." Flashes correspond to beeps or buzzes (through the soundcard, not the mobo piezo buzzer!), and seeing corresponds to listening through the microphone.

This may be a bit awkward over very large room distances due to the speed of sound, but I doubt it'll be an issue (if so, decrease rate of beeping).

这篇关于如何在不可靠的网络上同步媒体播放?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！