Long delay in the audio interfaces during a call |
|||
Issue descriptionDuring a call, the delay in the audio interfaces was long (in the order of 400 ms). This is much longer than what it should be. The issue occurred on a MacBook Pro and an aecdump recording is available. In this case, the issue was associated with constant echo issues and that could be verified, but not reproduced based on the data in the recording (due to the fact that the recording started ion the middle of the call). It is likely that the echo issues are associated with the long delay.
,
Nov 29 2016
Henrik, could you take a look at why the delay is so large?
,
Nov 30 2016
peah@ looked at the mic input recording and it is aligned with the AEC input signal - i.e. no delay jumps between those two points. It would be nice to have an output recording for this kind of case ( issue 531883 ). We talked about trying to repro this. Apart from that, there isn't much to act on to figure out the reason for this. Per: do you know if there is a WebRTC log for the call?
,
Dec 1 2016
Start with trying to repro. I also think the output recording is something we want to do, but I don't think it would be enough in this case.
,
Dec 1 2016
Sorry, there was no log uploaded for the call The Chrome version running was 55.0.2883.52 (Official Build) beta (64-bit) 6a89113b-a7aa8ed 68ebfce2-f23d1dea 90757ebb-f23d1dea 1e528f0f-ca7d8d80 38eb801c-3f4a17df 7c1bc906-8122a015 2a33b90e-84952c0a 1c752ce9-1b410b2f ba3f87da-f23d1dea f049a919-3f4a17df 27e74072-186f5907 31362330-3f4a17df c70841c8-a2567007 f15c1c09-ca7d8d80 9e201a2b-65bced95 5274eb09-3f4a17df 1a5bac38-3f4a17df 9e5c75f1-efb39c19 6b121ae7-ca7d8d80 f5dd6118-2f5721af f79cb77b-3f4a17df b7786474-d93a0620 23a898eb-4c21fc8d 74df3f1-3f4a17df 868bda90-f23d1dea 4ea303a6-3d47f4f4 9736de91-ca7d8d80 dbffab5d-ca7d8d80 3326cd71-3f4a17df ad6d27cc-c6d02f41 ca314179-ca7d8d80 69bf80fa-f23d1dea 867c4c68-3f4a17df b2f0086-93053e47 3ac60855-3ec2a267 f296190c-7da8925a 4442aae2-a90023b1 ed1d377-e1cc0f14 75f0f0a0-4ad60575 e2b18481-6bdfffe7 e7e71889-4ad60575 828a5926-71de01c2
,
Dec 1 2016
Are there stats in place that can catch this when it happens?
,
Dec 7 2016
Per: Not sure. For UMA stats, there's the AEC delay jump stats and you know those better. For getStats, I'm not familiar with those. I could find the non-standard googEchoCancellationEchoDelayMedian on the send side and googCurrentDelayMs on receive. No idea if they are relevant, do you know? Also, can you repro this? I can try, you just measured in the AEC dump signals, right?
,
Dec 20 2016
I have no idea about those stats. I have no repro of this case. What I did was to measure in the .wav files from the AEC dump recording.
,
Dec 21 2016
OK, thanks. If you could look into those AEC stats, that would be great. I would be good to add something - stats and/or log - when we detect this. Do you think you could look at this? I don't see how to find out why the delay is large in this case. Another data point is that NewAudioRenderingMixingStrategy experiment is enabled, although it's hard to tell if it could be related. (It's unlikely.)
,
Jan 2 2017
As far as I can see we have two options of detecting the delay: 1) Logging the audio buffer sizes. 2) Estimating the delay from the data. For 2) we could probably use some of the AEC stats. As that is an estimate of the delay, it has some uncertainty though, and since this (probably?) does not happen often, I'm not sure if we can rely on that to be able to either pinpoint the cause of this, or assess the magnitude of the issue. Furthermore, for the call where this was observed, there are strong indications that the delay estimator in the AEC failed to estimate the delay which means that the high delay in this call would not have been detected by this technique. I would rather prefer 1) if that is possible as that is an direct measure (not an estimate) of the delay. It excludes the acoustic delay but that is negligible in this case. Would it be possible to log: a) The lengths of the WebRTC audio buffers that reside in the echo path (as seen by the AEC). b) The lengths of the soundcard buffers. An alternative to always logging these lengths would be to only log when these buffers becomes longer than expected.
,
Jan 11 2017
OK, agree it sounds better to log/detect the audio buffer sizes, based on your information (thanks for the details). Currently in Chrome, the total delay is accumulated along the way to WebRTC, separately for recording and playout. I'm not sure what you mean with "WebRTC audio buffers", is it all the buffers in the pipeline between AEC and the soundcard? (I.e. WebRTC and Chrome.) It would be good to separate it. One option is to let Chrome detect unexpected changes in its code and the soundcard, and let WebRTC handle its code.
,
Jan 13 2017
By "WebRTC audio buffers" I mean anything that is buffering the audio from when it leaves the APM for playout to when the capture signal is received by the APM.
,
Feb 9 2018
Old bug - closing. We now have delay logging to traces in several places in the pipeline. https://chromium-review.googlesource.com/c/chromium/src/+/866716 |
|||
►
Sign in to add a comment |
|||
Comment 1 by grunell@chromium.org
, Nov 24 2016Status: Assigned (was: Untriaged)