CODEWITHSUNDEEP
signal-processingweb-audio-api
JSmith
JSmith

Reputation: 4810

How can I restitue a raw audio data stream using WebAudio?

I use WebAudio API and basically my setup is fairly simple.

I use 1 AudioWorkletNode as an emitter and another one as a receiver

emitter:

  process(inputs, outputs) {

    inputs[ 0 ].length && this.port.postMessage( inputs[ 0 ] );

    return ( true );

  }

receiver:

  inputs = [ new Float32Array(128), new Float32Array(128) ]

  constructor() {
    super();

    // Create a message port to receive messages from the main thread
    this.port.onmessage = (event) => {

      this.inputs = event.data.inputs;

    };

  }

  process( inputs, outputs) {

    const output = outputs[0];

    for (let channel = 0; channel < output.length; ++channel) {

      output[ channel ].set( this.inputs[ channel ] );

    }

    return true;
  }

on client side I have

//emitter
    this.inputWorklet.port.onmessage = e => this.receiverWorklet.port.postMessage( { inputs: e.data } );

and for receiving the data I have connected the nodes together

this.receiverWorklet.connect( this.gainNode );

This works but my problem is that the sound is really glitchy One thing I though of is there might be a delay between events also WebAudio is in a DOM context

Do you have any ideas How I could achieve a fluid stream restitution? or maybe another technique?

Upvotes: 0

Views: 104

Answers (1)

chrisguttandin
chrisguttandin

Reputation: 9136

The reason for the glitchy audio is that your code only works if everything always happens in the exact same order.

  • The input worklet's process() function needs to be called. It sends an event.
  • The event needs to pass through the main thread.
  • The event needs to arrive at the receiver worklet.
  • Only after that the receiver worklet's process() function needs to be called.

Since there is no buffer it always has to happen in the exact same order. If for some reason the main thread is busy and it can't process the events right away the receiver will continue playing the old audio.

I think you can almost keep the current implementation by buffering a few events in your receiver worklet before you start playing. It will of course also add some latency.

Another approach would be to use a SharedArrayBuffer instead of sending events. Your input worklet would write to the SharedArrayBuffer and your receiver worklet would read from it.

Upvotes: 2

Related Questions