The poorly performing but widely implemented 'Audio Element'
And the high performance but spottily implemented 'WebAudio API'
When we launched Revel last April, the WebAudio API was in bad shape, and mostly implemented only in chrome and a few other webkit variants.
So we made due with with the Audio Element; which has very high latency, some platform specific bugs, and requires a bit of extra work for out needs.
In Revel we use 'Audio Sprites' which means all of our sound effects are merged together in a single sound with silence breaks (padding) between each one; and has a table of contents that maps sound effect id's to positions and durations.
This is because it reduces HTTP transfer overhead dramatically, and the audio element is very difficult to work with and can exhibit bugs if you use too many of them playing simultaniously.
This meant cueing up the audio element to the proper location to play a sound, and setting a timer to go off to stop the sound after the specified length of the sound.
As you can guess the precision was not great; and suffered under heavy system load; but it generally did the job.
Now thankfully we detect for, and will use the higher performance Web Audio API; so far in tests audio is much more responsive, it seems perhaps a bit clearer; and the API is designed specificaly to play segments from start positions and durations in a buffer; so overruns seem non-existant.
