ehsanakhgari

Joined 14 years ago

Karma
317
Submissions
23
Member since
Mar 7
Mozilla hacker
View on Hacker News

Recent submissions

Comment · 1 year ago
can you explain the TPO technique or perhaps point me to a reference please?
Comment · 11 years ago
Yes, this is using the same built-in Tracking Protection feature.
Comment · 11 years ago
Yes. Over the years we have worked on projects that would reduce the impact of bugs found by this fuzzer. For example we have prevented whole classes of security bugs that this fuzzer would find, which would reduce the priority of fixing them compared to a benign crash.
Comment · 11 years ago
Yes, this is now common practice for all browser vendors, AFAIK.
Comment · 12 years ago
I assume you're mentioning https://wiki.mozilla.org/Audio_Data_API. After we implemented Web Audio, we deprecated and removed support for the Audio Data API.
Comment · 13 years ago
If you hit problems porting that to Firefox, please get in touch with me, would be happy to help you!
Comment · 13 years ago
For whatever it's worth, we have deprecated support for the Mozilla Audio Data API in favor of Web Audio, and will remove support for it in the near future.
Comment · 13 years ago
Comment · 13 years ago
Comment · 13 years ago
Comment · 13 years ago
If you hit latency issues in Firefox, please get in touch with me. Note that we currently have a rather high latency on Android, which we have plans to fix, but things should work fairly well on desktop platforms.
Comment · 13 years ago
Great to hear that! Is this project publicly available somewhere by any chance?
Comment · 13 years ago
About the first and third points, it would be great if you can send detailed feedback to this mailinglist: http://lists.w3.org/Archives/Public/public-audio/. Doing that would give us a chance to discuss these issues and fix the spec if possible.

About the second point, that's not accurate. All audio processing in a conforming Web Audio implementation happens on a background thread reserved for audio processing, which does not need to wait for things happening on the main thread (including GC pauses.) In practice, Gecko's processing model uses message passing between the audio thread and the main Javascript thread. WebKit and Blink use locks to synchronize the two threads some of the times, but the locking is minimal and it should not have a huge impact on performance.

About the testing issue, the working group has started to work on it recently, and you can see the beginning of the work here: https://github.com/w3c/web-platform-tests/tree/master/webaud.... We're planning to integrate the regression tests from both Mozilla and WebKit into the test suite for the spec (http://mxr.mozilla.org/mozilla-central/source/content/media/... and http://trac.webkit.org/browser/trunk/LayoutTests/webaudio) into the test suite. And of course, contributions for more tests are always welcome.

Comment · 13 years ago
We currently support MP3 playback for Windows Vista+ and Android if I'm not mistaken, and support for other platforms is being worked on. Web Audio will support all of the codecs supported by <audio> depending on the platform.
Comment · 13 years ago
Do you have specific complaints? We're definitely eager to hear about them at the Audio working group.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton