{"id":9878,"date":"2023-03-24T20:07:27","date_gmt":"2023-03-24T16:07:27","guid":{"rendered":"https:\/\/krisp.ai\/blog\/?p=9878"},"modified":"2025-03-12T14:28:41","modified_gmt":"2025-03-12T10:28:41","slug":"breaking-the-audio-processing-barrier-on-the-web-with-krisp-js-sdk","status":"publish","type":"post","link":"https:\/\/krisp.ai\/blog\/breaking-the-audio-processing-barrier-on-the-web-with-krisp-js-sdk\/","title":{"rendered":"Breaking the audio processing barrier on the web with Krisp JS SDK"},"content":{"rendered":"

In today’s world, browsers have become an integral part of our daily lives. Although Krisp worked on various native libraries for most platforms in use (Windows, Mac, Linux, Android, IOS), there were still many use cases where Krisp SDK was needed in the context of web applications. This article summarizes our journey of creating world-class noise cancellation SDKs for web usage. We believe this is a unique usage of Web Assembly, which showcases the unlimited possibilities that WASM has to offer. We put a lot of time and effort into this project and have delivered a game-changing JS SDK, enabling many products to level up their web-based real-time communication.<\/p>\n

Challenges<\/h2>\n

Processing audio in the browser is more challenging than it may seem at first glance. We faced different challenges. Some were well-known and had defined technical solutions. In contrast, some challenges were particular to our use case and we had to get creative. Let’s review some of our main challenges and discuss the solutions we came up with.<\/p>\n

Run C++ directly on the web.<\/h3>\n

Our first challenge when working on Krisp’s JS SDK was that our core SDK is C++ based and we needed to find a way to use our core SDK’s functionality inside a browser. We found a well-known solution for that: WASM (WebAssembly)<\/a>. This binary instruction format allows running programming languages such as C and C++ in the browser and achieving near-native performance on the web. To compile our C++ library into a WASM module, we used Emscripten<\/a>: a complete compiler toolchain to WebAssembly, with a primary focus on performance in web platforms. After compiling C++ into a WASM module, we can import that module to our javascript\/typescript project and use it (see Figure 1).<\/p>\n

\"WASM<\/p>\n

Figure 1. WASM module usage<\/p>\n<\/div>\n

Using our NC models<\/h3>\n

After understanding how to use our C++ code, we faced another problem: using our noise cancellation models. Up until this point, we were using our models in a native context and we didn’t have to worry about the size of our models that much. But everything changes in the context of web applications where you can’t load 30 or 40 MB of data every time while opening the application. To solve this problem, our research team worked on smaller yet fully functional models focused on performance. In Figure 2, you can see the comparison between our regular and small models.<\/p>\n

\"Native<\/p>\n

Figure 2. Model size comparison<\/p>\n<\/div>\n

128 samples per frame limitation<\/strong><\/h3>\n

With native development, you have flexibility and control over your audio flow. However, there are some limitations you have to consider while working with audio inside a browser. Audio circulates in frames (see Figure 3). Each frame consists of 128 samples (a sample is just a number describing the sound). There is also a term called sample rate – the number of samples we will receive per second. The sample rate may vary based on the device (you may have already seen the sample rate characteristic in audio devices’ descriptions).<\/p>\n

\"Sample<\/p>\n

Figure 3. Audio frames in web<\/p>\n<\/div>\n

Now, with this information, it is reasonably easy to understand how many seconds\/milliseconds of audio is stored in the given number of samples based on our sample rate. The sample count divided by the sample rate will provide us with the number of seconds stored in that sample count. To make the calculation even more helpful, we can multiply the result by 1000 to get the answer in milliseconds.<\/p>\n

Example:<\/strong>\u00a0Let’s say our sample rate is 48000 Hz, and we need to understand the duration of audio stored in one frame. One frame holds 128 samples; therefore, the calculation is as follows:<\/p>\n

(128 \/ 48000) * 1000 = 2.66ms.<\/p><\/blockquote>\n

So what exactly was our problem? Our SDK needs at least 10 milliseconds of audio to process, while the browser gives and expects to receive 128 sample frames. Our solution was to create a buffering system that will:<\/p>\n

a) Accumulate 10 milliseconds of audio and send that chunk to our WASM module to process b) Take the processed audio from the WASM module, split it into 128 sample frames, and return it to the browser (See Figure 4).<\/p>\n

\"Diagram<\/p>\n

Figure 4. A simplified diagram of our buffering system operations<\/p>\n<\/div>\n

 <\/p>\n

After handling these initial challenges, nothing stopped us from creating our first version of Krisp JS SDK.<\/p>\n

The first version of Krisp JS SDK<\/h2>\n
\"JS<\/p>\n

Figure 5. Simplified diagram of our first version of Krisp JS SDK<\/p>\n<\/div>\n

In Figure 5, you can see the simplified architecture diagram of our prototype of JS SDK.<\/p>\n

C++ side<\/h3>\n

Krisp Audio SDK is the C++ library we needed to run in Javascript. We also added a 128-sample state machine to it to track the state of the audio data and ensure audio consistency. Krisp WASM Processor is a middleware to create Emscripten bindings, allowing us to use methods from C++ on our Javascript side. As you can see, a buffering system is included here, which works with the state machine. Everything is compiled from this point, and we get our WASM Module.<\/p>\n

JS Side and Web Audio API<\/h3>\n

We needed to work with Web Audio API<\/a> to process the audio on our javascript side. Web Audio API provides a robust system to process audio on the web. Three main concepts were important in our use case: AudioContext, AudioWorkletProcessor, and AudioWorkletNode. Let’s go over each of these shortly. AudioContext is basically an audio graph that lets you manipulate audio sources and process the audio with various effects and processors before passing it into the audio destination (see Figure 6).<\/p>\n

\"JS<\/p>\n

Figure 6. The basic structure of AudioContext<\/p>\n<\/div>\n

AudioWorkletProcessor is capable of receiving input audio and setting the output audio. The interesting part is that you can manipulate audio in its process() method in between. In our case, we imported the WASM Module to the same krisp.processor.js file and started using it in the process() method, taking the cleaned audio and setting it as output.<\/p>\n

After writing the necessary code for the processor, the final step would be to integrate that processor into the AudioContext graph somehow. For that, in our krispsdk.js file, we c<\/span>reated our filter node using AudioWorkletNode, which takes our processor and adds it to the audio context’s graph.<\/p>\n

\"Snippet<\/p>\n

Simplified look at the connection between AudioWorkletNode, AudioWorkletProcessor, and AudioContext<\/p>\n<\/div>\n

So, at this point, we already got our first working prototype, but there were several issues with it.<\/p>\n

Issues with our first version<\/h3>\n

Buffering system on the C++ side<\/strong><\/h4>\n

Although our initial version worked, we encountered some issues with our buffering system. First of all, we implemented all the buffering logic on our C++ side, and as a result, that system was getting compiled into the WASM Module. And although we implemented logic to ensure that audio was consistent, the buffer’s location could have been more practical, as there was still a chance of losing audio data between processing. It is essential to note that the buffering system was an additional middleware.<\/p>\n

Terminating AudioWorkletNode<\/strong><\/h4>\n

Another issue was that we couldn’t entirely terminate our AudioWorkletNode, which resulted in multiple memory leak issues. Also, because of the same problem, we couldn’t handle device change based on the sample rate. We should re-initialize our SDK with a proper NC model optimal for that sample rate to ensure the best quality.<\/p>\n

Providing NC models separately<\/strong><\/h4>\n

And our last issue was that we were providing our NC models separately in a folder so that they could be hosted on our client’s side and imported to JS SDK with static URLs. Seeing all these issues, we started working on solutions and came up with a new version of JS SDK.<\/p>\n

The new version of Krisp JS SDK<\/h2>\n
\"New<\/p>\n

Figure 7. The new architecture of Krisp JS SDK<\/p>\n<\/div>\n

We developed core architectural improvements to eliminate the problems mentioned above (see Figure 7). Let’s go over each of them.<\/p>\n