Re: Intent to ship: Web Speech API - Speech Recognition with Pocketsphinx
Hi Marco. SpeechRTC was my first tentative with the platform. At early 2013 neither I had enough knowledge about gecko internals as even b2g was at very early stage (in the very beggining, Steven Lee needed to send me patches to gum work properly), so the fastest path was capture and stream online. The great part is that opus is pretty efficient plus nodejs + a speech server wrapping pocketsphinx turned the whole roundtrip really fast. But I knew that was not ideal for command and control / grammar, then I started to research a direct port of pocketsphinx using emscripten. Did work but three reasons made me move to a full cpp version: 1) the whole speech api frontend in gecko was ready to roll only waiting a backend, and this, as we know was built in cpp; 2) my tests ran very well, but on peak [2] for example, performed slower than on low end devices running android [3] 3) with emscripten, the model loading inside decoder's creation at each reload ended very slow and I couldn't figure out how to keep the decoder instance between tabs and reloads while in cpp this happens only once, due Gecko's architecture On Oct 31, 2014 12:27 AM, Marco Chen mc...@mozilla.com wrote: Hi Andre, It is a nice work and expect the voice recognition on B2G. Beside this final result, I am also interesting in the reason of you migrate from SpeechRTC - emscripten - Web Speech API. Could you also share what is the factor triggered these transition? Then that can be the lesson learn for us. ex: SpeechRTC - voice recognition can't be performed on local. emscripten - performance issue? or license issue? or ? Thanks, Sincerely yours. -- *From: *Andre Natal ana...@gmail.com *To: *dev-platform@lists.mozilla.org, Sandip Kamat ska...@mozilla.com, Olli.Pettay opet...@mozilla.com *Sent: *Friday, October 31, 2014 7:18:06 AM *Subject: *Intent to ship: Web Speech API - Speech Recognition with Pocketsphinx I've been researching speech recognition in Firefox for two years. First SpeechRTC, then emscripten, and now Web Speech API with CMU pocketsphinx [1] embedded in Gecko C++ layer, project that I had the luck to develop for Google Summer of Code with the mentoring of Olli Pettay, Guilherme Gonçalves, Steven Lee, Randell Jesup plus others and with the management of Sandip Kamat. The implementation already works in B2G, Fennec and all FF desktop versions, and the first language supported will be english. The API and implementation are in conformity with W3C standard [2]. The preference to enable it is: media.webspeech.service.default = pocketsphinx The required patches for achieve this are: - Import pocketsphinx sources in Gecko. Bug 1051146 [3] - Embed english models. Bug 1065911 [4] - Change SpeechGrammarList to store grammars inside SpeechGrammar objects. Bug 1088336 [5] - Creation of a SpeechRecognitionService for Pocketsphinx. Bug 1051148 [6] Also, other important features that we don't have patches yet: - Relax VAD strategy to be les strict and avoid stop in the middle of speech when speaking low volume phonemes [7] - Integrate or develop a grapheme to phoneme algorithm to realtime generator when compiling grammars [8] - Inlcude and build models for other languages [9] - Continuous and wordspotting recognition [10] The wip repo is here [11] and this Air Mozilla video [12] plus this wiki has more detailed info [13]. At this comment you can see a cpu usage on flame while recognition is happening [14] I wish to hear your comments. Thanks, Andre Natal [1] http://cmusphinx.sourceforge.net/ [2] https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1051146 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1065911 [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1088336 [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1051148 [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1051604 [8] https://bugzilla.mozilla.org/show_bug.cgi?id=1051554 [9] https://bugzilla.mozilla.org/show_bug.cgi?id=1065904 and https://bugzilla.mozilla.org/show_bug.cgi?id=1051607 [10] https://bugzilla.mozilla.org/show_bug.cgi?id=967896 [11] https://github.com/andrenatal/gecko-dev [12] https://air.mozilla.org/mozilla-weekly-project-meeting-20141027/ (Jump to 12:00) [13] https://wiki.mozilla.org/SpeechRTC_-_Speech_enabling_the_open_web [14] https://bugzilla.mozilla.org/show_bug.cgi?id=1051148#c14 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Web Speech API - Speech Recognition with Pocketsphinx
Sorry, I forgot the links: 2 - Speechrtc offline on Firefox OS (Peak): http://youtu.be/FXKXhrRDEb8 3 - Continuous speech recognition on android with poc…: http://youtu.be/3lTtCFaQF2A On Nov 9, 2014 11:12 AM, Andre Natal ana...@gmail.com wrote: Hi Marco. SpeechRTC was my first tentative with the platform. At early 2013 neither I had enough knowledge about gecko internals as even b2g was at very early stage (in the very beggining, Steven Lee needed to send me patches to gum work properly), so the fastest path was capture and stream online. The great part is that opus is pretty efficient plus nodejs + a speech server wrapping pocketsphinx turned the whole roundtrip really fast. But I knew that was not ideal for command and control / grammar, then I started to research a direct port of pocketsphinx using emscripten. Did work but three reasons made me move to a full cpp version: 1) the whole speech api frontend in gecko was ready to roll only waiting a backend, and this, as we know was built in cpp; 2) my tests ran very well, but on peak [2] for example, performed slower than on low end devices running android [3] 3) with emscripten, the model loading inside decoder's creation at each reload ended very slow and I couldn't figure out how to keep the decoder instance between tabs and reloads while in cpp this happens only once, due Gecko's architecture On Oct 31, 2014 12:27 AM, Marco Chen mc...@mozilla.com wrote: Hi Andre, It is a nice work and expect the voice recognition on B2G. Beside this final result, I am also interesting in the reason of you migrate from SpeechRTC - emscripten - Web Speech API. Could you also share what is the factor triggered these transition? Then that can be the lesson learn for us. ex: SpeechRTC - voice recognition can't be performed on local. emscripten - performance issue? or license issue? or ? Thanks, Sincerely yours. -- *From: *Andre Natal ana...@gmail.com *To: *dev-platform@lists.mozilla.org, Sandip Kamat ska...@mozilla.com, Olli.Pettay opet...@mozilla.com *Sent: *Friday, October 31, 2014 7:18:06 AM *Subject: *Intent to ship: Web Speech API - Speech Recognition with Pocketsphinx I've been researching speech recognition in Firefox for two years. First SpeechRTC, then emscripten, and now Web Speech API with CMU pocketsphinx [1] embedded in Gecko C++ layer, project that I had the luck to develop for Google Summer of Code with the mentoring of Olli Pettay, Guilherme Gonçalves, Steven Lee, Randell Jesup plus others and with the management of Sandip Kamat. The implementation already works in B2G, Fennec and all FF desktop versions, and the first language supported will be english. The API and implementation are in conformity with W3C standard [2]. The preference to enable it is: media.webspeech.service.default = pocketsphinx The required patches for achieve this are: - Import pocketsphinx sources in Gecko. Bug 1051146 [3] - Embed english models. Bug 1065911 [4] - Change SpeechGrammarList to store grammars inside SpeechGrammar objects. Bug 1088336 [5] - Creation of a SpeechRecognitionService for Pocketsphinx. Bug 1051148 [6] Also, other important features that we don't have patches yet: - Relax VAD strategy to be les strict and avoid stop in the middle of speech when speaking low volume phonemes [7] - Integrate or develop a grapheme to phoneme algorithm to realtime generator when compiling grammars [8] - Inlcude and build models for other languages [9] - Continuous and wordspotting recognition [10] The wip repo is here [11] and this Air Mozilla video [12] plus this wiki has more detailed info [13]. At this comment you can see a cpu usage on flame while recognition is happening [14] I wish to hear your comments. Thanks, Andre Natal [1] http://cmusphinx.sourceforge.net/ [2] https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1051146 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1065911 [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1088336 [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1051148 [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1051604 [8] https://bugzilla.mozilla.org/show_bug.cgi?id=1051554 [9] https://bugzilla.mozilla.org/show_bug.cgi?id=1065904 and https://bugzilla.mozilla.org/show_bug.cgi?id=1051607 [10] https://bugzilla.mozilla.org/show_bug.cgi?id=967896 [11] https://github.com/andrenatal/gecko-dev [12] https://air.mozilla.org/mozilla-weekly-project-meeting-20141027/ (Jump to 12:00) [13] https://wiki.mozilla.org/SpeechRTC_-_Speech_enabling_the_open_web [14] https://bugzilla.mozilla.org/show_bug.cgi?id=1051148#c14 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list
Re: e10s is now enabled by default for Nightly!
Three? I've only seen two... Really three or more depending on the number of plugins you have running, usually just flash. Plugin processes are now owned by the chrome process so, chrome, a single process for content for now, and a set of plugin processes. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: e10s is now enabled by default for Nightly!
Another annoying session-restore bug that just appeared in the last 4-5 days https://bugzilla.mozilla.org/show_bug.cgi?id=1095726 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: the 'box-decoration-break' CSS property
On Friday, July 11, 2014 7:38:39 PM UTC+2, Mats Palmgren wrote: IE10 has -ms-box-decoration-break I've tested[1] this property in IE11 with the values slice and clone. IE does not seem to support it. (I've also checked in older versions via Document Mode in F12 tools.) [1]: http://jsbin.com/zusuwo/1/edit?css,output ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: e10s is now enabled by default for Nightly!
On Sat, Nov 8, 2014 at 2:39 PM, Mike Hommey m...@glandium.org wrote: BTW, does AWSY deal with e10s? That's an excellent question... I suspect not. I wonder if it'll get confused or just report measurements (e.g. explicit, resident) for one of the processes. AWSY's a little behind and it's most recent measurements are from Nov 5, slightly before e10s was turned on by default. And this reminds me of https://bugzilla.mozilla.org/show_bug.cgi?id=1024021: a lot of the telemetry results will be messed up by e10s, because they'll only be measuring the chrome process. In some cases that'll be fine, in some cases the content processes measurements should be added to the chrome process's, and in some cases they should be reported separately... Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: e10s is now enabled by default for Nightly!
On Sun, Nov 9, 2014 at 2:35 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: BTW, does AWSY deal with e10s? That's an excellent question... I suspect not. I wonder if it'll get confused or just report measurements (e.g. explicit, resident) for one of the processes. I just looked at the code and I *think* it'll sum all the individual reports from the two processes and present them as if they came from a single process. Which is probably the least worst way it can fail to handle e10s properly -- it's a bit weird but the results won't be crazy :) But we should fix things to report them separately. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: e10s is now enabled by default for Nightly!
On Sun, Nov 09, 2014 at 03:21:57PM -0800, Nicholas Nethercote wrote: On Sun, Nov 9, 2014 at 2:35 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: BTW, does AWSY deal with e10s? That's an excellent question... I suspect not. I wonder if it'll get confused or just report measurements (e.g. explicit, resident) for one of the processes. I just looked at the code and I *think* it'll sum all the individual reports from the two processes and present them as if they came from a single process. Which is probably the least worst way it can fail to handle e10s properly -- it's a bit weird but the results won't be crazy :) But we should fix things to report them separately. RSS will be skewed by libraries being counted twice, though. And compensating by substracting the size of those libs won't be enough because of their relocatable parts being different in the different processes. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: e10s is now enabled by default for Nightly!
E10s also breaks EME Gecko Media Plugins, and probably OpenH264 as well. Bug 1057908 should fix that... Chris Pearce. On 11/7/2014 1:27 PM, Chris Peterson wrote: The patch is on mozilla-inbound and ought to hit mozilla-central in time for tomorrow's Nightly build. \o/ https://hg.mozilla.org/integration/mozilla-inbound/rev/a75897e664dd e10s will not ride the trains to Aurora 36. Talos and unit tests will continue to run for e10s and non-e10s until e10s hits the Release channel. Some known problems: * IME and a11y will disable e10s until support is completed * Some performance problems with Adblock Plus * Bug 947030 - Ghostery add-on does not block trackers * Bug 972507 - BugzillaJS add-on does not work [1] * Bug 1008768 - LastPass add-on does not fill in form fields * Bug 1014986 - HTTPS Everywhere add-on breaks HTTP redirects * Bug 1042680 - Tree Style Tabs add-on does not work * Bug 1042195 - 1Password add-on does not work * Bug 1058542 - NoScript add-on does not work * Bug 1093161 - Searching from address bar does not work the first time If you have any questions, drop by #e10s on IRC. If you file new bugs related to e10s, please include the word e10s in the summary so the e10s team's triage queries will find your bug. chris [1] btw, BugzillaJS is seeking a new maintainer: https://www.yammer.com/mozillians/#/threads/show?threadId=454089406 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozReview ready for general use
It's quite common for me to be working on a bug that depends on another bug that hasn't landed yet. I'm struggling to figure out how to make this work with MozReview, since everything is lumped into one review group and associated with one bug. ie, I have: * Bug 1 - patch A (this is either waiting for review, or hasn't landed on m-c yet) * Bug 2 - patch B (I want to put this up for review) If I push this to reviewboard, both patches get automatically grouped together and associated with Bug 1. I can specify --reviewid to make them get associated with Bug 2, but that also puts Bug 1's patch in Bug 2. (Note that I'm using MQ, because I can't figure out how to do this via bookmarks either.) - Blair Gijs Kruitbosch wrote: All of hg.m.o is currently 503 https://bugzilla.mozilla.org/show_bug.cgi?id=1094922 ~ Gijs On 06/11/2014 16:58, Benoit Girard wrote: Cool. I'm eager to try this out. Sadly https://hg.mozilla.org/hgcustom/version-control-tools is giving me a 503 error at this time. On Wed, Nov 5, 2014 at 11:50 PM, Mark Côté mc...@mozilla.com wrote: A couple months ago I gave a sneak peak into our new repository-based code-review tool based on Review Board. I'm excited to announce that this tool, now named (descriptively but unimaginatively) MozReview, is ready for general use. In the interests of beta-testing our documentation at the same time as our code, I want to mostly confine my post to a link to our docs: http://mozilla-version-control-tools.readthedocs.org/en/latest/mozreview.html Everything you need should be in there. The only item I want to highlight here is that, yes, we know the UI is currently not great. We bolted some stuff onto the basic Review Board interface for our repository-centric work flow. We're working on integrating that into a whole new look feel that will also strip out the bits that aren't as pertinent to our approach to code review. Please bear with us! We hope that, UI warts notwithstanding, you'll still enjoy this fresh approach to code review at Mozilla. Mark ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozReview ready for general use
We currently only attempt to map each review/commit series to a single bug. We will support multiple bugs eventually. Single bugs were easy to implement :) There is also an open bug to support specifying the base revision to review. Right now everything on the stack gets reviewed. That should hopefully get resolved this week. Keep the version-control-tools repo up to date. On Nov 9, 2014, at 17:25, Blair McBride bmcbr...@mozilla.com wrote: It's quite common for me to be working on a bug that depends on another bug that hasn't landed yet. I'm struggling to figure out how to make this work with MozReview, since everything is lumped into one review group and associated with one bug. ie, I have: * Bug 1 - patch A (this is either waiting for review, or hasn't landed on m-c yet) * Bug 2 - patch B (I want to put this up for review) If I push this to reviewboard, both patches get automatically grouped together and associated with Bug 1. I can specify --reviewid to make them get associated with Bug 2, but that also puts Bug 1's patch in Bug 2. (Note that I'm using MQ, because I can't figure out how to do this via bookmarks either.) - Blair Gijs Kruitbosch wrote: All of hg.m.o is currently 503 https://bugzilla.mozilla.org/show_bug.cgi?id=1094922 ~ Gijs On 06/11/2014 16:58, Benoit Girard wrote: Cool. I'm eager to try this out. Sadly https://hg.mozilla.org/hgcustom/version-control-tools is giving me a 503 error at this time. On Wed, Nov 5, 2014 at 11:50 PM, Mark Côté mc...@mozilla.com wrote: A couple months ago I gave a sneak peak into our new repository-based code-review tool based on Review Board. I'm excited to announce that this tool, now named (descriptively but unimaginatively) MozReview, is ready for general use. In the interests of beta-testing our documentation at the same time as our code, I want to mostly confine my post to a link to our docs: http://mozilla-version-control-tools.readthedocs.org/en/latest/mozreview.html Everything you need should be in there. The only item I want to highlight here is that, yes, we know the UI is currently not great. We bolted some stuff onto the basic Review Board interface for our repository-centric work flow. We're working on integrating that into a whole new look feel that will also strip out the bits that aren't as pertinent to our approach to code review. Please bear with us! We hope that, UI warts notwithstanding, you'll still enjoy this fresh approach to code review at Mozilla. Mark ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozReview ready for general use
On 11/9/14, 11:10 PM, Gregory Szorc wrote: We currently only attempt to map each review/commit series to a single bug. This is definitely a problem; it serializes workflow such that you have to get review on bug 1 and land it before you can even request review on bug 2 that depends on bug 1, no? This is a pretty common situation, unfortunately. We will support multiple bugs eventually. Do we have any estimate on timing? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
