for July, 2013


Intel8080 emulator: Explicit coercion fix for Chakra

I was pointing out recently the disappointing performance of JavaScript in IE11. As a test I was using the Intel8080 emulator I wrote a few months ago. John-David Dalton (PM for the Chakra VM at Microsoft)  kindly investigated the issue and came back with a one line fix, improving largely the performance. This was the line causing the issue (line 44 in screen.js):

Which should be changed to:

Posted on July 29, 2013 by Thibault Imbert · 0 comments Read More
JavaScript Web Audio

From microphone to .WAV with: getUserMedia and Web Audio

Update: The new MediaStream recording specification is aiming at solving this use case through a much simpler API. Follow the conversations on the mailing list.

A few years ago, I wrote a little ActionScript 3 library called MicRecorder, which allowed you to record the microphone input and export it to a .WAV file. Very simple, but pretty handy. The other day I thought it would be cool to port it to JavaScript. I realized quickly that it is not as easy. In Flash, the SampleDataEvent directly provides the byte stream  PCM samples) from the microphone. With getUserMedia, the Web Audio APIs are required to extract the samples. Note that getUserMedia and Web Audio are not broadly supported yet, but it is coming. Firefox has also landed Web Audio recently, which is great news.

Because I did not find an article that went through the steps involved, here is a short article on how it works, from getting access to the microphone to the final .WAV file, it may be useful to you in the future. The most helpful resource I came across was this nice HTML5 Rocks article which pointed to Matt Diamond’s example, which contains the key piece I was looking for to get the Web Audio APIs hooked up. Thanks so much Matt! Credits also goes to Matt for the merging and interleaving code of the buffers which works very nicely.

First, we need to get access to the microphone, and we use the getUserMedia API for that.

Posted on July 22, 2013 by Thibault Imbert · 52 comments Read More

Concurrency in JavaScript

Just like with Flash, JavaScript code runs by default on the UI thread, and any expensive computation will usually affect the UI responsiveness. As you may know, at 60 fps, you have around 16ms (1000ms/60) per frame to do what you have to do (computations, rendering and other misc logic). If you exceed that budget, you will alter the frame rate and potentially make your content feel sluggish or worse, unresponsive.

Frame budget

Frame budget

Web Workers are now broadly available in most browsers even on mobile ( stats for Web Workers) and give you the power of concurrency from within JavaScript. It will allow you to move expensive computations to other threads, to permit best responsive programming, and ideally open the doors in the future to true parallelization in JavaScript. Let’s have a look at the reasons why you may be interested into leveraging Web Workers.

  • Responsive programming: When you have an expensive computation and don’t want to block the UI.
  • Parallel programming: When you want to leverage multiple CPU cores by having computations running concurrently to solve a specific task.

We will see later on that parallel programming with Web Workers can be challenging, and that they are not really designed for that today unfortunately. But before we dive into the details of responsive programming and parallel programming, let’s start with some more details about Web Workers. Note that we will cover here dedicated Web Workers, not the shared Web Workers.

Posted on July 1, 2013 by Thibault Imbert · 28 comments Read More