W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

[Bug 17415] (JSWorkers): JavaScriptAudioNode processing in workers

From: <bugzilla@jessica.w3.org>
Date: Fri, 27 Jul 2012 16:38:57 +0000
Message-Id: <E1SunZ3-0001dB-KR@jessica.w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 July 2012 16:39:02 GMT