User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/59.0.3071.109 Chrome/59.0.3071.109 Safari/537.36 Steps to reproduce: 1. Define MediaStream() instance as a variable 2. Define MediaRecorder() instance as a variable, pass MediaStream instance as first parameter to MediaRecorder, with mimeType set to "audio/ogg; codecs=opus" 3. Call navigator.mediaDevices.getUserMedia(), selecting Monitor of Built-in Audio Analog Stereo 4. Get audio track from media stream with .getAudioTracks() 5. Set audio track to previously defined MediaStream with .addTrack() 6. Call MediaRecorder .start() 7. Call window.speechSynthesis.speak() Actual results: The playback of recorded media is choppy. See plnkr https://plnkr.co/edit/7Y2ifjRK5K9YGwT9G8nn?p=preview Expected results: The playback of recorded media should not be choppy. See plnkr https://plnkr.co/edit/7Y2ifjRK5K9YGwT9G8nn?p=preview at Chromium browser

Can you check if this is real?

Yeah this has been a problem in the past when we used non-full-duplex capture, and non-direct listeners (which you have here since a constructed MediaStream is used). Using the stream from gUM directly should work but wouldn't skip video even if removeTrack()ed. I'd also verify if the user is on full duplex. If he is, we might have an unforeseen issue. It's related to (and hopefully fixed by) bug 1296531. I'll be back in August to answer more questions. I'll forward the ni? to Bruce to have some tracking.

Looking at this again. Like my last comment, I think the author can work around this issue by using the MediaStream returned from getUserMedia directly, because of the fixes in bug 1257318. This should get fixed by bug 1296531 for the remaining cases (tracks wrapped in a new stream specifically).