Bisect results:
You are probably looking for a change made after 493775 (known good), but no later than 493791 (first known bad).

https://chromium.googlesource.com/chromium/src/+log/2de71eade34e55b034df7b016e3e66fc9673c303..49054cb75299eec3c5498287183e384e85185706

I confirmed by locally building individual CLs that the issue starts with 

https://chromium.googlesource.com/chromium/src/+/622f1359f68a417d77e3907ceb93b5d63ef1df98

I'll take a look. It's a serialization error.
If I can't easily fix it, I'll revert the offending CL and its follow-up.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3c383683db9cce0d98953f0557d6b6948b3ab797

commit 3c383683db9cce0d98953f0557d6b6948b3ab797
Author: Guido Urdaneta <guidou@chromium.org>
Date: Tue Aug 15 13:52:48 2017

Fix handling of audio parameters in AudioInputDeviceManager.

Recent changes to use media::AudioParameters made sure input parameters
were always valid, but there was no check for the parameters of the
associated output device.

BUG= 755248 

Change-Id: Idfabf8ce1bf86756ea6cf08dc6bf895b798b3057
Reviewed-on: https://chromium-review.googlesource.com/615243
Reviewed-by: Olga Sharonova <olka@chromium.org>
Commit-Queue: Guido Urdaneta <guidou@chromium.org>
Cr-Commit-Position: refs/heads/master@{#494370}
[modify] https://crrev.com/3c383683db9cce0d98953f0557d6b6948b3ab797/content/browser/renderer_host/media/audio_input_device_manager.cc
[modify] https://crrev.com/3c383683db9cce0d98953f0557d6b6948b3ab797/content/browser/renderer_host/media/audio_input_device_manager_unittest.cc

in which canary version, we we expect to see this fix?

I guess the fix will make it to the next canary build after the current one.

guido@: Thanks so much for getting in a fix for this so quickly. I haven't analyzed the root cause and fix yet, but I feel we should add a test case to catch similar regressions in the trybot runs. It seems this particular issue did not happen when using the fake device, which is used in almost all our automated tests. We probably need to create a test with a differently configured fake device to cover this case.

danny@: If you don't want to wait for the next canary, you may be able to do your tests on one of the continuous builds for revisions >= 494370, e.g. https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win_x64/494376/

I created  issue 755578  to track the work for adding test coverage.

chfremer@: The root cause was that the work to replace content::AudioDeviceParameters with media::AudioParameters overlooked (at least) one instance where default-constructed audio parameters were used and sent to the renderer process.

The problem is that default-constructed content::AudioDeviceParameters were serializable while default-constructed media::AudioParameters are not serializable.

In getUserMedia calls involving audio, audio parameters for the microphone and its associated device are read and sent to the renderer. When the microphone has no associated device, the audio manager returns a default-constructed media::AudioParameters as output parameters.

The original code had checks to ensure that the microphone parameters were valid and serializable (even though they were converted to AudioDeviceParameters), but there were no such checks for the associated output parameters.
My patch fixed this by making the same checks for the associated output parameters and updated one test to prevent regressions.

Sorry, I was not able to look into this issue as I was OOO due to our national holiday here. guidou@chromium.org: Thanks for the quick fix.

 Issue 755842  has been merged into this issue.