Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 5 of 5
  1. #1
    New to the CF scene
    Join Date
    Feb 2014
    Posts
    3
    Thanks
    0
    Thanked 0 Times in 0 Posts

    What Javascript Timer can be used to avoid being throttled by the browser?

    Hi, I'm looking for a Javascript timer (like SetTimeout) that will provide me 8ms or better timer accuracy is critical both in and out of tab focus, while avoiding the use of Web Workers.

    SetTimeout has a timer accuracy of 4ms in-focus, and an accuracy of 1000ms out-of-focus on chrome, and this causes major audio glitches to occur while the tab is out of focus.

    This is critical because this is for scheduling playback of music notes for WebAudio from a server with a 990ms delay, the last 10ms will be used by a CPU-taxing

    The reason I want to avoid using Web Workers with SetTimeout is that it was tested; while it works great on multi-core systems, it causes major system-hanging issues on single-core cpus.

    Do you guys know of any timers that will do what I need? (perhaps involving an external Javascript library if there's no native methods?)

  • #2
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    Use setInterval instead of setTimeout.

    With a setTimeout runs once and then you need to call one again to start the next delay.

    With a setInterval there is no delay to actually run the code as the function is added to the execution queue at the specified interval and one being slightly delayed will not cause the following ones to be delaed as well.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #3
    New to the CF scene
    Join Date
    Feb 2014
    Posts
    3
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by felgall View Post
    Use setInterval instead of setTimeout.

    With a setTimeout runs once and then you need to call one again to start the next delay.

    With a setInterval there is no delay to actually run the code as the function is added to the execution queue at the specified interval and one being slightly delayed will not cause the following ones to be delaed as well.
    SetInterval is also affected by throttling in the same way as SetTimeout when the tab is out of focus (inactive).

    This is what I want to avoid. Again. SetTimeout works perfectly when the tab is in focus and not throttled by the browser. SetTimeout has an accuracy of 4ms on chrome and the last 10ms of the note schedule is used by the CPU-taxing webaudio timer to ensure a hybrid between CPU efficiency and precision.

    (Actually, the WebAudio timer was used for the whole 1000ms of note scheduling previously, this worked find when tabs are both active and inactive, but it used up an unacceptable amount of CPU usage)

  • #4
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,401
    Thanks
    11
    Thanked 595 Times in 575 Posts
    i've used WebSockets to emit an event every 100ms on a server and it worked within about 2% on the client, owing to some lag. I don't know of many other ways to periodically invoke a routine on an inactive tab. The audio tag spits out a lot of "progress" events while playing. you might be able to play silence and use those events to get a regular and less than 1000ms periodic execution on a inactive tab, but they too might be throttled, i've never checked. You might also be able to rig something using css animation to grow and shrink a div, causing scroll events to be emitted. I can't think of anything else, so if none of that helps, i would strongly consider going with Workers if that works well on most machines; it might be your best shot at a good user experience. If you're only scheduling a timer event on the Worker "thread", i don't see how that would tax the CPU very much...
    Last edited by rnd me; 02-28-2014 at 04:05 PM.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/9/03) IE7:0.1, IE8:4.6, IE11:9.1, IE9:3.1, IE10:3.0, FF:17.2, CH:46, SF:11.4, NON-MOUSE:38%

  • #5
    New to the CF scene
    Join Date
    Feb 2014
    Posts
    3
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by rnd me View Post
    i've used WebSockets to emit an event every 100ms on a server and it worked within about 2% on the client, owing to some lag. I don't know of many other ways to periodically invoke a routine on an inactive tab. The audio tag spits out a lot of "progress" events while playing. you might be able to play silence and use those events to get a regular and less than 1000ms periodic execution on a inactive tab, but they too might be throttled, i've never checked. You might also be able to rig something using css animation to grow and shrink a div, causing scroll events to be emitted. I can't think of anything else, so if none of that helps, i would strongly consider going with Workers if that works well on most machines; it might be your best shot at a good user experience. If you're only scheduling a timer event on the Worker "thread", i don't see how that would tax the CPU very much...
    It could work, maybe it's not the best idea in this case, but could work like trade-off.
    100ms is a pretty big threshold. And net latency adds additional delay that could cause lag, and this approach would require additional calculations to decide which scheduled note should be played.


    Actually right now, the site has the Web Worker approach implimented. It works well for EVERYONE with multi-core machines, however it's problematic on systems with only 1 core.

    The problem seems to not be CPU-tax, but rather that the WebWorkers causes the browser (or whole system) to frequently hang for ~7 seconds at a time; at either random times or when several things are going on with the worker. That is, with the single-core visitors on google chrome. (the browser the site's been optimized for in the first place) I'm assuming this has to do with the single-core getting confused by the web-worker thread.

    Without the WebWorkers, the site is smooth on the single-core machine (p4 630) on chrome, just with unstable/muted audio when the site is brought to a background tab.


  •  

    Tags for this Thread

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •