New issue
Advanced search Search tips

Issue 872718 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug



Sign in to add a comment

Layout test audiocontextoptions.html fails on Linux

Reported by ysy...@gmail.com, Aug 9

Issue description

Chrome Version (from the about:version page): 70.0.3518.0 (from ./chrrome/VERSION)
Is this the most recent version: yes
OS + version: Ubuntu 16.04.5 LTS
CPU architecture (32-bit / 64-bit): 64
Window manager: Gnome
URLs (if relevant): NA
Behavior in Linux Firefox: NA
Behavior in Windows Chrome (if you have access to it): NA

What steps will reproduce the problem?
(1) Build Layout tests
gn gen out/Release
ninja -C out/Release blink_tests
(2) Run Layout test
python third_party/blink/tools/run_web_tests.py -t Release

What is the expected result?
All tests pass

What happens instead?
Test external/wpt/webaudio/the-audio-api/the-audiocontext-interface/audiocontextoptions.html fails with following error:
....
FAIL X balanced baseLatency is not greater than or equal to 0.011609977324263039. Got 0.01. assert_true: expected true got false
....

As I understand this test (external/wpt/webaudio/the-audio-api/the-audiocontext-interface/audiocontextoptions.html)
fails starting from https://chromium-review.googlesource.com/c/chromium/src/+/1067100 commit.

Before this commit fake audio device with low latency was used for latency measurement.
After this commit real audio device is used for latency measurement (media/audio/alsa or media/audio/pulse in linux case).

In terms of Chrome latency is equal frame_buffer_size / sample_rate
sample_rate is the same for all audio context types (i.e. for "balanced", "interactive" or "playback")
frame_buffer_size is differ for all types. It is calculated in content/renderer/media/renderer_webaudiodevice_impl.cc, GetOutputBufferSize.
for interactive it is equal some hardcoded value: 512 for pulse_audio or 2048 for alsa for example. For fake audio device it was 128 and this test finished successfully
for balanced it is equal sample_rate / 100 for Linux case. Starting from above-mentioned commit balanced latency becomes more then interactive one.
As result the test fails.

The strange thing is that according Google build bot result this test always passes (I checked actual results here: https://ci.chromium.org/p/chromium/g/chromium.linux/console).


 
Components: Blink>WebAudio
Status: Available (was: Unconfirmed)
Yeah, this is a known issue when running the layout tests locally on linux with real audio HW that has the sample rate set to 44.1 kHz.  The bots work because they normally don't have audio HW, so a fake device is used, and the fake device has a sample rate of 48 kHz, which makes the latency all work out.

The underlying issue is that on linux, the "low"-latency path uses a block size of 512 frames.  But in "balanced" mode, we use a latency that is appropriate for WebRTC which is a size of 10 ms.  At 44.1 kHz, that's 441 frames, which is lower than 512.

We've considered using 10ms with the low-latency path if it's less than 512 frames, but aren't sure about it.  This causes a bit of jitter in the processing, and pulseaudio has pretty terrible audio callback timing (which jitters a lot too).

Sign in to add a comment