Some headsets open up with huge soundcard buffer size |
||||||||||||||||||||||
Issue descriptionThis is a spin-off from https://bugs.chromium.org/p/chromium/issues/detail?id=905083, where it was found that some headsets use soundcard buffer sizes of 150 ms. The headsets mentioned in the bug are Jabra 9450, Jabra Pro 9460 Series, Logitech Dual H820e. It only happens on Windows (Windows 10 was reported in the bug).
,
Nov 19
We now have the Logitech Dual H820e available. Please, test it on Windows 10. Testing on Linux by gustaf@ does not show the same problem as reported for Windows. The API call jitter in AEC (which is an indictor of the buffer size used to access the sound card) is much smaller than what was observed in the original bug.
,
Nov 19
,
Nov 19
The two sets of variations in the original bug didn't have the IncreaseInputAudioBufferSize experiment enabled. If you can reproduce it's anyway good if you confirm that that experiment isn't related to this.
,
Nov 19
Started out by making a reference round-trip latency measurement using some known USB device and demo in [1] on a Windows 10 machine. SB Arena USB headset @ 48kHz => ~150-160 ms Logitech USB headset H340 @ 44.1kHz => ~95ms Tried with and without USB hub but using a hub did not affect the results. [1] https://sound.io/latency/
,
Nov 19
Installed the Logitech H820e device and one thing to note is that the input side only supports 16kHz which is very rare. In addition, it is not possible to change any audio parameter on the output side which is also very odd. Running a loopback test using WebRTC as in [1] shows that the round-trip latency is very long. I would estimate > 300ms. The test in [2] fails to detect any signals. Not sure why but the pulses sound distorted. [1] https://webrtc.github.io/samples/src/content/getusermedia/audio/ [2] https://sound.io/latency/
,
Nov 19
Also did some listing tests where I played music via Spotify and the audio quality is really bad on the output side as well. Most likely a combination of a low frequency range and other factors.
,
Nov 19
Re #4: most likely not related since the simple tests I've done so far shows extreme delays.
,
Nov 19
Attaching AECdump files. gustaf@: please take a look.
,
Nov 19
Thanks Henrik. It seems like the recording contains no reverse stream. Could you please record a new dump with both capture and reverse streams? It's needed for me to analyze the buffering.
,
Nov 19
Done.
,
Nov 19
Searched for dedicated drivers in [1] but there are none. [1] https://support.logitech.com/en_us/product/wireless-headset-dual-h820e-business/downloads
,
Nov 19
Also tried different Chrome media unittests on the device and we always open up both directions using buffer sizes less than 20ms. Hence, the device as such does not reveal that it produces extreme delays.
,
Nov 19
Intermediate summary regarding Logitech Dual H820e. The encountered long delay using this headset on Windows seems to be caused by internal buffer handling in the native driver and we (the Chrome audio layer) can most likely not change this fact.
,
Nov 20
I had a look at the aec_dump provided by henrika@ in #12 and it shows the same call pattern as the aec_dump provided by mcoser@twilio.com (in https://crbug.com/905083#c7 ). The audio processing module gets ~140 ms of audio from the reverse stream, then ~140 ms of audio from the capture stream and so on. The buffering on Linux using the same headset is ~40 ms.
,
Nov 20
Thanks for analyzing. Is there anything more for us to do here?
,
Nov 20
Let me do some more tests and I'll come back.
,
Nov 20
Did some progress. Summary of the latest state. Chrome Stable 70.0.3538.110: - Logitech H820 in both directions => very large round-trip latency - Logitech H820 for playout and SB Arena USB headset for recording => very large round-trip latency - Logitech H820 for recording and SB Arena USB headset for playout => OK latency Chrome Stable 72.0.3616.0: - Logitech H820 in both directions => audio output rendering fails for all audio clients - Logitech H820 for playout and SB Arena USB headset for recording => audio output rendering fails - Logitech H820 for recording and SB Arena USB headset for playout => OK latency Hence, the issue is on the playout side in Chrome using the Logitech H820. In Stable, output audio works but with an extreme latency and in Canary it does not work at all. Using the changes in https://chromium-review.googlesource.com/c/chromium/src/+/1335560 resolves these issues and we end up with low full-duplex latency in the latest Chrome.
,
Nov 20
,
Nov 20
And Chrome Beta (71.0.3578.53) has same issues as Chrome Stable BTW.
,
Nov 23
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f0d3de6b6d4a3b99873e0c64ba9d48cb0d53fb73 commit f0d3de6b6d4a3b99873e0c64ba9d48cb0d53fb73 Author: henrika <henrika@chromium.org> Date: Fri Nov 23 16:35:27 2018 Improvements in media::CoreAudioUtil::GetSharedModeMixFormat. The GetMixFormat method retrieves a format descriptor that is in the form of a WAVEFORMATEXTENSIBLE structure instead of a standalone WAVEFORMATEX structure. The method outputs a pointer to the WAVEFORMATEX structure that is embedded at the start of this WAVEFORMATEXTENSIBLE structure. Note that, crbug/803056 indicates that some devices can return a format where only the WAVEFORMATEX parts is initialized and we must be able to account for that. This CL improves usage of WAVEFORMATEX/WAVEFORMATEXTENSIBLE by introducing a wrapper structure called WaveFormatWrapper. The idea is to avoid assuming that the underlying structure is extended when it actually isn't even if a WAVEFORMATEXTENSIBLE is used. Also stops using WAVEFORMATPCMEX in the utility to avoid assuming PCM format. Bug: 803056, 905969 Change-Id: I6a9fe3e23b3537df81f9d4ed610c12935668a253 Reviewed-on: https://chromium-review.googlesource.com/c/1335560 Commit-Queue: Henrik Andreasson <henrika@chromium.org> Reviewed-by: Henrik Grunell <grunell@chromium.org> Reviewed-by: Oskar Sundbom <ossu@chromium.org> Cr-Commit-Position: refs/heads/master@{#610631} [modify] https://crrev.com/f0d3de6b6d4a3b99873e0c64ba9d48cb0d53fb73/media/audio/win/audio_low_latency_input_win.cc [modify] https://crrev.com/f0d3de6b6d4a3b99873e0c64ba9d48cb0d53fb73/media/audio/win/core_audio_util_win.cc [modify] https://crrev.com/f0d3de6b6d4a3b99873e0c64ba9d48cb0d53fb73/media/audio/win/core_audio_util_win.h [modify] https://crrev.com/f0d3de6b6d4a3b99873e0c64ba9d48cb0d53fb73/media/audio/win/core_audio_util_win_unittest.cc [modify] https://crrev.com/f0d3de6b6d4a3b99873e0c64ba9d48cb0d53fb73/media/base/audio_parameters.cc
,
Nov 30
Marking as fixed. Reassigned to initial reporter for final OK. |
||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||
Comment 1 by henrika@chromium.org
, Nov 16