What you’re hearing is the crowd cheering as you cross the finish line.

Looking back over the delivery of the requirements of your project, you’re beginning to think that maybe this mobile development stuff isn't quite as difficult as you once thought. So far, you have completed the first three requirements:

• Real-time access to IBM i data and local storage when no mobile connectivity is available
• Ability to take pictures, store them on the device, and upload them
• Ability to retrieve and store geolocation information

All you have left is requirement #4:

• Ability to record audio for taking “audio notes”

The sweet smell of victory wafts through the air! Smart programmers leverage what they know and try to follow DRY (Don't Repeat Yourself) principles (unless they’re being paid by the line of code!) so you think of the key components of the brilliant solutions you have delivered thus far:

• Local storage of JSON formatted text
• Use of Web RTC GetUserMedia methods

It's like Lex in Jurassic Park when he gets in front of that UNIX system: “I know this!” Yeah, we know this. Let's get started.

Capturing Audio

Capturing audio is a wee bit different than capturing an image. On the face of it, you'd think it would be more simple, but looks are deceiving! What made the image capture so slick was the HTML5 canvas object that the image was rendered to and then “exporting” that canvas image into a Base64 encoded string. Image to string...bada bing! But the audio capture has to be stored somewhere “as is” that we know what “is” is: an .ogg file on the local file system. Hmmm. More challenges.

Step 1: The Wizard of .ogg

Normally the “default” recording format for audio on digital devices is .wav. PCM (Pulse-code modulation) audio in a .wav container is the “standard” way to save audio on a computer, but a .wav file can be huge. Why? Compression algorithms, like those that compress audio into an MP3 (the most common container), are patented and licensed. Generally, that means that only the “spend money” command can wrest the code to compress the audio from the hands of the copyright holder. But MP3 is a published standard, and the patent trolls have slowly backed off to the point where non-commercial use isn't aggressively targeted. In any case, encoding a .wav into an MP3 container usually takes a third-party library (perhaps you have heard of LAME). So it looks like we need to stray outside of the “standard” browser toolkit if we want an MP3.

Several browsers have adopted the Vorbis/Opus format. This is a lossy format that performs well and is pretty ubiquitous across platforms and browsers. And, even though the format is covered by patents, the trolls look for other encroachments since the patents that might cover the Vorbis/Opus standard are royalty-free (the trolls lose!).

Capturing a Vorbis/Opus formatted audio stream in a “.ogg” container is as easy as capturing an image. It all starts with this:

navigator.getUserMedia(constraints, startRecording, errorCallback);

Constraints are typically something like {"audio": true, "video": "false" } and the two callbacks are for a successful initialization or/a failure.

Step 2: Save the Recording

If the API is successful in accessing the recording device, then the end user will be prompted to allow access, just like with the camera capture. The next step is...what is the next step? At this point, we need to do something with the captured audio. Unlike our camera capture, where we could use the canvas object to display the video until we captured the snapshot, we want to record the audio and then save it to a file for later playback and/or upload. Our canvas object had a canvas.toDataURL method we could call to render the data in the canvas object. What about our audio?

So a brief aside here to outline the journey taken to the solution. My original hope was that I could just record the audio to an object and then automatically save it to a file. So I naturally went to look for a file-writing API and easily found one that dates back to 2011 (2009 spec). So the steps were to get the BLOB that contained the audio and write it out to the local file system. The success callback takes a stream object as a parameter, and that can be written to the file system, right? Wrong! The very cool file system APIs were never formally adopted and, at least for file writing, died due to lack of implementation across browsers in 2014.

There are several third-party libraries that can help with the capture and storage of audio, but I wanted to avoid third-party libraries. Just before I was going to tuck my tail between my legs and crawl back into the boss's office to tell her I couldn't meet the last requirement (I promised, remember?), I discovered some bleeding-edge code that bailed me out. The Media Capture Task Force, a team populated by both WebRTC and Device API working groups, had proposed a standard that only Firefox had originally implemented. But within the last month, Chrome had also implemented the API in the latest version of the browser (well, version 49 and forward) in April 2016. The jury is still out on Safari, Opera, and Edge, but Chrome is the 800-pound gorilla in the browser space, so it’s just a matter of time. In any case, our Android smartphones use Chrome. “The crops are saved!”

So, the MediaRecorder API comes to the rescue:

var mediaRecorder = new MediaRecorder(stream); // Sweet! It takes the stream object from our callback function!

var chunks = []; // store our accumulated recording data in an array

mediaRecorder.ondataavailable = function(aud) {
      chunks.push(aud.data);
};

When we’re done recording, we'll want to create a BLOB so we can save the recording:

var blob = new Blob(chunks, {type: "audio/ogg"});
var audioURL = window.URL.createObjectURL(blob);

downloadLink.href = audioURL;
audioElement.src = audioURL;
downloadLink.innerHTML = 'Download the file';

At this point, we have a link we can click, and it, in turn, prompts the user to save the file locally. You could also push that file up to the server with a standard file transfer. Yet another approach would be to convert your BLOB to a Base64-encoded string and store it in local storage and then decode it when you retrieve it. The challenge is that the encoded audio, even in a lossy format like Vorbis, can still be pretty big (and you know how salespeople can talk!). You may exceed the 5mb limit on local storage.

Done!

Success! Your salespeople can record notes on their nifty web application. Your tasks are complete, and you can rest a bit…before your boss gives you the next big challenge.