Mic echo

[NTShop]

When I have my headphones on with audio enabled and mic enabled, and I start streaming and cue the mic I hear myself talk with a slight delay of about 250 - 500ms or thereabouts. It sounds like Webcaster is feeding the mic audio back to the person talking into the mic somehow and it's very distracting to hear that with the delay. For example, I may start a MP3 song playing in a playlist and have something to say about the song while it starts playing, I hear the MP3 in real time and my own voice but with that slight delay as I speak over the top of the MP3. This also happens when no MP3 is playing.

To be clear, it's not the mic picking up audio from the headphones and feeding it back, it's definitely coming from Webcaster somehow.

Is there any way to mod the code so that doesn't happen?

[toots]

Hi,

Thanks for reporting this. As far as I can tell it is a current limitation of the Javascript Web API: http://stackoverflow.com/questions/21428511/playing-and-recording-with-a-constant-latency-on-browser-with-javascript-usermed

I'll keep an eye on this.

[NTShop]

After some investigating it appears this delay in hearing one's own voice is due to the controlsNode which is a createScriptProcessor that handles calculating the volume levels for the left and right channels for the on-screen level meters for the mic and two playlists, and for display track playback progress. The processor has a buffer size, the larger it is the more latency there is. But even setting it to the lowest possible of 256 creates latency.

I think there's probably a better way to handle all that without introducing much of any latency other than from the gain nodes to handle real volume control and the passthrough buffer processing.

One path could be: Instead of using a script processor use an analyzer (createAnalyzer) and standard HTML5 canvas to display the volume meters. For track playback progress instead of using "new Audio()" use a HTML5 tag and hook some JS/CSS to that for styling and display purposes - this route lets the browser native core handle the entire playback process where the JS acts as an interface to control the playback / progress / pause / volume stuff.

[toots]

Ok, it looks like the control node is not facing passThrough. However, passThrough itself is a script node as well. I've reduced its latency to the minimal. Could you try now?

[NTShop]

I tried that myself, going from 256 all the way up to 8192. The problem is that at a lower value ( below 1024 ) the audio becomes choppy or gravely (if that makes sense to you) as heard via Icecast. So I'd suggest raising back to where you had it. In my case I disabled the "Track.prototype.createControlsNode" script processor since I don't need volume meters. That reduced a lot of overhead. Then for the passThrough script processor I have the buffer set to 2048.