Reproducible on 25 Beta 4 (BuildID: 20131001024718): Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:25.0) Gecko/20100101 Firefox/25.0 Reproducible on the latest Aurora (BuildID: 20131002004002): Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:26.0) Gecko/20100101 Firefox/26.0 Reproducible on the latest Nightly (BuildID: 20131001030204): Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:27.0) Gecko/20100101 Firefox/27.0 Steps to reproduce: 1. Launch Firefox. 2. Navigate to http://webaudioplayground.appspot.com/ 3. Open a Live Input node. 4. Select the Mic device and click Share Selected Device. 5. Connect the nodes. 6. Talk on the microphone. Expected results: The voice is heard clearly. Actual results: The sound is jerky and I can hear myself twice. Notes: 1. On Ubuntu, Windows XP, Windows 7 and Windows 8 everything sounds good. Reproduced on two different Mac machines. 2. I`m not sure if this is a regression but with mozregression I`m getting this: Last good nightly: 2013-08-07 (this is good because the Live Input does not work at all so maybe it wasn't implemented yet) First bad nightly: 2013-08-08 (this is where the jerky sound is heard and duplicated) Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1fb5d14e8348&tochange=fd4cf30428b0

Karl, can you take a look at this please? Thanks!

I don't have a Mac, sorry, and this is specific to the Macs. Bogdan, can you check that you don't hear yourself through the speakers/headphones when the live input node is not connected, please? If you do, please test again before loading the webaudioplayground. There should be an operating system sound control somewhere to turn off mic playback, keeping only mic capture .

> Bogdan, can you check that you don't hear yourself through the > speakers/headphones when the live input node is not connected, please? On a Mac OS X 10.8.4 machine, I can't indeed hear myself in this situation, the behavior being the same with 25 beta 4 in 32-bit mode and Chrome. > If you do, please test again before loading the webaudioplayground. > There should be an operating system sound control somewhere to turn off mic > playback, keeping only mic capture. As far as I know, the mic playback is off by default on Mac, but I also checked in the settings and it was off.

Over to Maire to find an owner.

Hey Paul, I know you have access to a Mac. Could you take a look at this?

I have more info about the problem. If you start the browser, go to http://mozilla.github.io/webrtc-landing/gum_test.html and run any gUM test (audio or video) and then go to http://webaudioplayground.appspot.com/, everything sounds good. If you reverse the tests and go http://webaudioplayground.appspot.com/ first after starting the browser, it sounds horrible (as reported in this bug) AND gUM audio also sounds horrible when you then try the gUM audio test afterwards. Audio stays in a bad state until you restart the browser. I ran a debug build and got logs from a good run and a bad run with NSPR_LOG_MODULES=mediamanager:5,getusermedia:5,mediastreamgraph:5. I'll upload them next. Rob -- Could you take a look at the logs and see if you notice anything useful? This feels like an issue with how MediaStreamGraph is being initialized -- but I only know enough about MediaStreamGraph to be slightly dangerous. :-)

This was a log from the good run. I ran a gUM test first and then ran the Web Audio test. Audio sounded good for the rest of the session.

This is the log from the bad run. I ran the Web Audio test first followed by the gUM test. Not only did Web Audio sound terrible but gUM did also. Audio sounded bad for the rest of the session.

So, I've tested this on my macbook, using today's nightly build, it works just fine: I cannot hear a difference between: - Running the gUM piped to the <audio> first, WebAudio right after - Running WebAudio, then the gUM to <audio> - Running both pages at the same time (I hear very short latency difference between the <audio> output and the WebAudio output, but this is expected, as the route taken in both cases is different). I tried reloading multiple times, but I cannot repro. I'm running OSX 10.8.5, with all the recent system updates. Maire, are you running 10.7 by any chance? Comment 3 and the report hints to a 10.7-only bug. I might be able to find a 10.7 machine, if it is indeed a 10.7 specific bug.

In fact, I managed to borrow a colleague's OSX 10.7 machine, and I could not repro.

Ok, this is a screwy bug. I think it's a USB issue and only if Web Audio is used before gUM. It matters which devices you select for the first use of Web Audio after starting the browser. If I use an analog headset (for mic and speaker), the sound is good (I can't repro). If I use a USB headset, I hear the bug (I CAN repro). If I take the mic from the analog and output it to the speaker of the USB, the audio is good (can't repro). If I take the mic from the USB headset and output to the analog headset, the audio is good (can't repro). So, if I use a USB headset for mic and speaker AND use Web Audio as the first thing I do after starting the browser, I hear the bug (I can repro). If I use gUM first, I never hear the problem. If I don't use a USB headset, I can't repro the bug. FYI: I'm running OSX 10.7.5 MacBook Pro.

I was also able to repro this with two additional USB headsets. My first headset was Logitech H540. My second and third headsets were Logitech H555 and Plantronics Audio 626 DSP. NOTE: When I switched the speaker output from the USB headset to the internal speaker on the Mac, audio delay increased and the bug (the horrible sound) eventually went away and sounded "normal" (though delayed by a couple of seconds). I know internal drivers typically have longer delay (so that didn't surprise me -- I know we're working to reduce that) but I was surprised that the garbling and double talk went away after about a minute. I tried the same test feeding the speaker output to audio headset speakers and the poor audio continued (with no noticeable delay).

Nominating this for tracking given this blocks bug 779297.

Same question as in bug 923106 - does this bug actually block the ability to ship Web Audio as a whole? We're in our second to last week of Beta so if this is something that can be fixed by a follow up in FF26 please let us know.

This is affecting a particular release of OSX (we believe it only affect 10.7, but this is just anecdotal correlation, I could not even repro myself to diagnose), with very specific STR. It might very well be a bug in a driver. I don't think this is important enough nor actionable (yet, although I'm hoping to be able to repro today) to prevent us from shipping WebAudio.

Agreed, let's not consider this a blocker for the feature's release.

I tried on a couple different macbooks running 10.7 (different hardware generation different minor version), and I can't repro.

This is not really a web audio api bug, and we've fixed things like that a while ago, please reopen another bug if this still happens.