- From: <bugzilla@jessica.w3.org>
- Date: Fri, 27 Jul 2012 16:38:57 +0000
- To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415 --- Comment #70 from Grant Galitz <grantgalitz@gmail.com> 2012-07-27 16:38:56 UTC --- (In reply to comment #60) > > - We need a reliable main-context event system for scheduling audio actions > > (setInterval is not up to it, it seems). > > There can't be any truly reliable way to schedule audio actions on the main > thread. > > I doubt you can do better than setInterval plus some way to measure audio > progress, such as mozCurrentSampleOffset. Funny story, mozCurrentSampleOffset is essentially non-functional on Linux Firefox. Timing audio off of it has been broken since it was introduced. The callback for more samples method is best because it tells me exactly how many samples it needs. With mozCurrentSampleOffset and mozWriteAudio we were actually exposed to each OS's buffering edge cases, and still are! I have the user agent sniff for windows Firefox for instance to insert a shadow 100 ms of extra buffering otherwise windows Firefox stops the audio clock. This is in contrast to Mac Firefox being perfect at all buffer levels. Why even a faulty mozCurrentSampleOffset is better than no buffering determination: Being forced to use time stamps to generate audio from the lack of audio clock access though would be much much worse, as things like sleep events and time zone changes will kill the timed logic. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Friday, 27 July 2012 16:39:02 UTC