Tracking the spec changes...

FYI, we used floats in the media code, then switched to doubles. When we were using floating point we kept accumulating floating point errors over time which caused imprecision and in some cases stuttery playback. Finally we switched to use int64 microseconds for our internal time stamps, and we now convert timestamps to floating point in seconds just before we return them JS. I'm not sure if this is relevant to you; you may not be accumulating floating point values, but it's something you need to be aware of.

Comment on attachment 683275 [details] [diff] [review] Patch (v1) r=me

(In reply to comment #2) > FYI, we used floats in the media code, then switched to doubles. > > When we were using floating point we kept accumulating floating point errors > over time which caused imprecision and in some cases stuttery playback. > > Finally we switched to use int64 microseconds for our internal time stamps, and > we now convert timestamps to floating point in seconds just before we return > them JS. > > I'm not sure if this is relevant to you; you may not be accumulating floating > point values, but it's something you need to be aware of. Thanks. That's not directly relevant to the current implementation, but it's definitely something worth being aware of as we move forward. :-)

Mass moving Web Audio bugs to the Web Audio component. Filter on duckityduck.