更新：我得出的结论是，整个事情只是谷歌浏览器版本32中引入的一个烦人的错误，所有改变计时器的方法都是避免实际的错误根源而不是推动铬开发人员解决它..
请查看此主题：https://code.google.com/p/chromium/issues/detail?id=356772
已归档的主题内容
我有一个专为Chrome设计的webaudio音乐网站 试图帮忙，我需要一些建议：
客户收到音乐笔记后，即会安排笔记 通过定时器在指定的延迟后运行（默认为1000ms） 补偿网络ping问题。
最初，这是通过使用WebAudio本地计时器完成的 全部1000毫秒。到目前为止，这对CPU来说非常沉重 一次安排约600个音符。 （考虑到这是我的 了解所有这些笔记每回一个回调，并且是 被迫不跳过任何回调）
最近制作了一个补丁，其中SetTimeOut将被用于 计划的第一个990ms和其余的WebAudio。这样做了 巨大的性能提升。
有一个问题，如果标签失焦，浏览器 限制SetTimeout / SetInterval的精度从4ms到1000ms， 更改标签时会导致毛刺/非工作音频。那么一个 已经添加了一个解决方法，并对该网站提出了建议; 创建一个WebWorker线程并将SetTimeout渲染放入其中。 这在多核系统上非常有效，但这会导致主要问题 悬挂单核系统（系统和/或浏览器）的问题 电平）。
最重要的是，我认为解决这个问题的真正方法是避免使用 Web-Workers解决方法并使用不同的计时器系统 SetTimeout或SetInterval以避免页面不可见性限制。所以， 什么是使用具有相同（或更少）CPU占用空间的好计时器 作为Javascript，具有8ms或更高的准确性，并且不受限制 通过浏览器？