after NPAPI ?
Hi, I maintain a plugin using NPAPI and I'm looking for durable solution. My plugin is a link between web page and sound processing. I record the voice, apply some math, and inject in real time in the headset. It's a like a guitar effect but for the voice. Do you know how I could interface C++ and Web? On Internet Explorer I use ActiveX, but how I will do it when NPAPI disappear? Thanks for your answer. Best regards, Philippe ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Test coverage?
Hi, Currently we have many tests that are skipped for various reasons. Do we have data on which test runs on which platforms? For example if a test is accidentally skipped on all platforms, could we identify it? Kanru ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Test coverage?
On 25/11/2014 10:40, Kan-Ru Chen (陳侃如) wrote: Hi, Currently we have many tests that are skipped for various reasons. Do we have data on which test runs on which platforms? For example if a test is accidentally skipped on all platforms, could we identify it? Kanru A tool called "Test Informant" reports to this list once a week with a summary of how many tests are disabled on which platforms/runtimes. (We're slightly overdue on last week's report - not sure why. Andrew?) ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: after NPAPI ?
On Tue, Nov 25, 2014 at 11:20 AM, wrote: > My plugin is a link between web page and sound processing. I record the > voice, apply some math, and inject in real time in the headset. > It's a like a guitar effect but for the voice. > > Do you know how I could interface C++ and Web? > On Internet Explorer I use ActiveX, but how I will do it when NPAPI disappear? I think the future-proof solution would be to compile your C++ code to asm.js using Emscripten, and use the getUserMedia() HTML 5 API to do the sound recording. Cheers, Dirkjan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: after NPAPI ?
Hi, If I read correctly, asm.js execute code in a sandbox. I don't think a sandbox let me access to the wasapi drivers of the soundcard. Best regards, Philippe On Tuesday, November 25, 2014 1:37:40 PM UTC+1, Dirkjan Ochtman wrote: > I think the future-proof solution would be to compile your C++ code to > asm.js using Emscripten, and use the getUserMedia() HTML 5 API to do > the sound recording. > > Cheers, > > Dirkjan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: after NPAPI ?
On Tue, Nov 25, 2014 at 2:28 PM, wrote: > If I read correctly, asm.js execute code in a sandbox. I don't think a > sandbox let me access to the wasapi drivers of the soundcard. Why do you need to access those drivers/what are you using them for? Cheers, Dirkjan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: http-schemed URLs and HTTP/2 over unauthenticated TLS
On Fri, Nov 21, 2014 at 5:44 PM, Patrick McManus wrote: > On Fri, Nov 21, 2014 at 10:09 AM, Anne van Kesteren > wrote: >> Why would they be allowed to use OE? > > The reasons why any individual resource has to be http:// and may (or may > not) be able to run OE vary by resource. Of course only the content provider > can know their reason for sure. I've tried to point out in this thread what > some of those reasons can be and its really not very relevant whether you or > I agree with them unless we own the content. Well you brought up the nosslsearch example, presumably in defense of OE. To me it seems then reasonable to ask if they could use OE in such a scenario. > They are doing this with opportunistic encryption (via the > Alternate-Protocol response header) for http:// over QUIC from chrome. In > the past they did this with spdy too (I'm unsure of current status of that). > They don't want the open and standards track web to participate. It seems we > can't be trusted to do what they're already proprietarily doing for their > own services. Google is unwilling to standardize QUIC? Or are you saying that because Google experiments with OE in QUIC, including in services today through Chrome, it is weird for them to oppose OE in HTTP? -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: after NPAPI ?
> Why do you need to access those drivers/what are you using them for? Hi, I need to get the audio sample data and do some math on it, then play it in the speaker, with the minimum of latency (arround 20ms). Only the wasapi driver could allow this. The calculus on the samples depends of web params, and the start and stop too. Best regards, Philippe ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: http-schemed URLs and HTTP/2 over unauthenticated TLS
Hi Anne, On Tue, Nov 25, 2014 at 9:13 AM, Anne van Kesteren wrote: > > > They are doing this with opportunistic encryption (via the > > Alternate-Protocol response header) for http:// over QUIC from chrome. > In > > > > Or are you saying that > because Google experiments with OE in QUIC, including in services > today through Chrome, it is weird for them to oppose OE in HTTP? > Its interesting because of what it says about the actual options instead of the arguments we make about them. Google is trying hard to be https:// everywhere and yet they still have to run http:// services. That illustrates how hard a full transition is - most people can't match the kind of resources to spend on the problem that google has, and yet google hasn't been 100% successful. The rest of the web does far worse - heck we just launched our new h.264 Cisco addon download over http:// (with an external integrity check). When running http:// google has twice made an engineering decision to do so with OE and something better than h1. The result is better than plaintext-h1 and we should also be striving to bring our users and the whole web the same benefits. "This site runs better in Chrome" sucks. What we're going to do is make https better faster and cheaper as the long play to ubiquitous real security, and in the short term offer folks more encryption and better transports on http:// too because we hope to reach more of them that way. Plaintext is the last choice and is maintained strictly for compatibility - nobody wins when we do that. -P [I think we're firmly into the recycling phase again :)] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: after NPAPI ?
On 25/11/2014 14:22, rayna...@gmail.com wrote: I need to get the audio sample data and do some math on it, then play it in the speaker, with the minimum of latency (arround 20ms). Only the wasapi driver could allow this. Have you actually tried using getusermedia/web audio for this? Or are you just speculating? What does the wasapi driver provide that the web's APIs don't? ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Test Informant Report - Week ending Nov 21
Test Informant report for 2014-11-21. State of test manifests at revision 5ba06e4f49e8. Using revision a52bf59965a0 as a baseline for comparisons. Showing tests enabled or disabled between 2014-11-15 and 2014-11-21. 87% of tests across all suites and configurations are enabled. Summary --- marionette- ↑0↓0 - 92% mochitest-a11y- ↑8↓0 - 99% mochitest-browser-chrome - ↑36↓17 - 94% mochitest-browser-chrome-e10s - ↑88↓2 - 48% mochitest-chrome - ↑40↓8 - 97% mochitest-plain - ↑244↓98 - 86% mochitest-plain-e10s - ↑72↓32 - 79% xpcshell - ↑67↓8 - 92% Full Report --- http://brasstacks.mozilla.com/testreports/weekly/2014-11-21.informant-report.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Test coverage?
Sorry the service fell over on the weekend so I'm missing data for Sat-Mon. I just posted a report up to and including last Friday though: http://brasstacks.mozilla.com/testreports/weekly/2014-11-21.informant-report.html Daily reports should be uploaded again starting tomorrow: http://brasstacks.mozilla.com/testreports/daily/ Sorry for the inconvenience! -Andrew On 25/11/14 06:42 AM, Gijs Kruitbosch wrote: On 25/11/2014 10:40, Kan-Ru Chen (陳侃如) wrote: Hi, Currently we have many tests that are skipped for various reasons. Do we have data on which test runs on which platforms? For example if a test is accidentally skipped on all platforms, could we identify it? Kanru A tool called "Test Informant" reports to this list once a week with a summary of how many tests are disabled on which platforms/runtimes. (We're slightly overdue on last week's report - not sure why. Andrew?) ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: after NPAPI ?
> On Nov 25, 2014, at 13:22, Gijs Kruitbosch wrote: > > On 25/11/2014 14:22, rayna...@gmail.com wrote: >> I need to get the audio sample data and do some math on it, then play it in >> the speaker, with the minimum of latency (arround 20ms). >> >> Only the wasapi driver could allow this. > > Have you actually tried using getusermedia/web audio for this? Or are you > just speculating? > > What does the wasapi driver provide that the web's APIs don’t? Low latency. I’m no audio expert, but my understanding is that a 20ms round-trip is _very_ fast. See: https://wiki.mozilla.org/Media/WebRTC_Audio_Issues#Audio_Latency_--_bug_785584 https://wiki.mozilla.org/Gecko:MediaStreamLatency#Windows -- reuben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: after NPAPI ?
Gecko should be able to make 10-40ms audio round trips, including processing. It is of course using WASAPI behind the scenes, and the latency will depend on the audio hardware. Gecko will try to use the lowest latency possible in any case (both on input and output). Then again, if you need to write custom processing code, you need another piece of the puzzle: the AudioWorkerNode [0]. This is a mecanism to be able to run JavaScript code in the audio callback. It is not implemented in any browser right now, but the effort is tracked in bug 1062849 [1]. You can _try_ to use the old ScriptProcessorNode in the meantime, it's not the best but it can work. It will increase the latency a bit, but at least you can try porting your code. I hope to be able to reduce the input latency further by using full-duplex streams, for WebRTC and input processing like this, but this will take some time. Let me know if you want any more info, Paul. [0]: http://webaudio.github.io/web-audio-api/#the-audioworker [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1062849 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Components.returnCode not working as expected.
On Sun, Nov 23, 2014 at 4:43 PM, Mark Hammond wrote: > * Is Components.returnCode expected to be used when the code throws (as > SessionStore.jsm does) or when the code returns without an exception? (Or > maybe both?) > It doesn't look like it's used much in the tree, but it seems like the one unique use-case it solves is returning a code without throwing. So I think we should make it do that (and document the IDL). > * If it is supposed to be used with a normal return, is the change so > GetPendingResult() is called the correct approach to take? (ie, should I > open a bug with that as the patch?) > At a high level yes, but I haven't looked at the code to determine if that precise fix is right. Please file a bug with the patch flag me for review. bholley ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: after NPAPI ?
On 11/25/2014 05:45 PM, Reuben Morais wrote: On Nov 25, 2014, at 13:22, Gijs Kruitbosch wrote: On 25/11/2014 14:22, rayna...@gmail.com wrote: I need to get the audio sample data and do some math on it, then play it in the speaker, with the minimum of latency (arround 20ms). Only the wasapi driver could allow this. Have you actually tried using getusermedia/web audio for this? Or are you just speculating? What does the wasapi driver provide that the web's APIs don’t? Low latency. I’m no audio expert, but my understanding is that a 20ms round-trip is _very_ fast. Not really. Nowhere near enough for music production. One needs to get the round-trip latency to <10ms. See: https://wiki.mozilla.org/Media/WebRTC_Audio_Issues#Audio_Latency_--_bug_785584 https://wiki.mozilla.org/Gecko:MediaStreamLatency#Windows -- reuben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Critical - XULRunner 34 fails with "Couldn't load XPCOM" in MacOSX
The new XULRunner 34 fails with "Couldn't load XPCOM" error when running MacOSX. It works fine in Win32. Besides, FF34 works fine too. Anyone any idea what caused this? XULRunner 33 works fine in MacOSX too. I'm using OS X Yosemite. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
prebuilt libraries?
Would it make sense to check in some of the libraries we build that we very rarely change, and that don’t have a lot of configure dependencies people twiddle with? (icu, pixman, cairo, vp8, vp9). This could speed up build times in our infrastructure and for developers. This doesn’t have to be in mozilla-central. mach could pick up a matching binary for the current configuration from github or similar. Has anyone looked into this? Thanks, Andreas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: prebuilt libraries?
On Tue, Nov 25, 2014 at 10:50:45PM -0800, Andreas Gal wrote: > > Would it make sense to check in some of the libraries we build that we > very rarely change, and that don’t have a lot of configure > dependencies people twiddle with? (icu, pixman, cairo, vp8, vp9). This > could speed up build times in our infrastructure and for developers. > This doesn’t have to be in mozilla-central. mach could pick up a > matching binary for the current configuration from github or similar. > Has anyone looked into this? That's on the TODO list for sccache. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Components.returnCode not working as expected.
On 11/25/2014 10:28 AM, Bobby Holley wrote: On Sun, Nov 23, 2014 at 4:43 PM, Mark Hammond wrote: * If it is supposed to be used with a normal return, is the change so GetPendingResult() is called the correct approach to take? (ie, should I open a bug with that as the patch?) At a high level yes, but I haven't looked at the code to determine if that precise fix is right. Please file a bug with the patch flag me for review. FWIW, this is bug 287107 - it would be useful to check against when happened when an attempt was made to fix it in 2005 (and got backed out). There are few callers that use this API in tree because it's been broken for nearly a decade :) -- Mook ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
