I assume that's the sample rate of the AEC recording? Do we know the system sample rate for that stream/call?

The sample rates were the same. I.e. the sample rate in the wav file stored in audio_input_controller.cc was the same as in the audio processing module. Furthermore, both were stored as 32 bit float.

Thanks! I failed to mention that. 

Can you attach the differing files? Is it an LSB diff, time shift or something else?

I can send them to you offline. The diff I did was in matlab as:
a = audioread('file1.wav');
b = audioread('file1.wav');
norm(a-b)
plot([a-b a])

No time-shift was required, the files are of the same lengths it is quite clear that there is no shift between them (I tested by introducing an artificial shift of 1 sample which caused the norm to be much larger).

I took a further look and the bitinexactness is really supersmall

The samples are 32 bit floats and the error is 2^-30. Maybe it is not worth looking into, and maybe it is caused by the recording/reading of the float pcm data.

But if it is expected to be bitexact, my concern is that this is caused by some processing code which is not needed (and does almost nothing) for this sample rate. One such could be a resampler that does resampling with the input frequency equal to the output frequency.

I would suspect float<->int conversions. Chrome passes around audio as floats in AudioBus objects, but it is converted to 16 bits before being pushed to WebRTCs AudioTransport::OnData(), then obviously converted to floats again. Since the error is so small, that indicates Chrome gets its data in 16 bit format from the sound card originally.

Yes, WebRTC should take floats instead.

That makes sense. Should have known that :-). 

Yes, WebRTC should take floats instead. 

From that, this difference is actually expected.

Then I think this can be closed.