Issue metadata
Sign in to add a comment
|
AudioContext sampleRate is often incorrect after page reloads
Reported by
douggerh...@gmail.com,
Aug 10 2017
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36 Steps to reproduce the problem: 1. Attach two microphones with two different sample rates to the computer 2. Open the sample page found here: https://s3.amazonaws.com/chrome-audiocontext-samplerate/index.html 3. Select one of the microphones, allow the page to run for 15-20s and note the sample rate over time 4. *Refresh* the same page, and select the other microphone; its initial reported sample rate will be incorrect, but by initializing (and closing) new AudioContexts, eventually we'll start being given contexts with the correct sample rate. (I've attached logs of this behaviour below.) What is the expected behavior? Chrome should create an audio context with the correct sample rate. What went wrong? Chrome reports the wrong sample rate initially, then, later, new audio contexts will be generated with the correct sample rate. I've attached a log of this behaviour below (and as an attachment). Note, the following audio devices are attached to the system: - Built-in audio: 44.1khz - Mpow Wolverine: 16khz In this case, we're selecting the built-in audio, which is being given the sample rate of the wolverine. 2017-08-10T20:39:24.478Z [init] starting up 2017-08-10T20:39:24.478Z [init] getting media permission... 2017-08-10T20:39:24.626Z [init] got media permission; eunmerating devices 2017-08-10T20:39:25.214Z [enumerateDevices] source: Default 2017-08-10T20:39:25.215Z [enumerateDevices] source: Mpow Wolverine 2017-08-10T20:39:25.216Z [enumerateDevices] source: Built-in Microphone 2017-08-10T20:39:28.869Z [startWithSource] called; deviceID=443285103e9bc07dfa2dcb8af28d19c6546167afa9a59ef6203cf23dd06396ff 2017-08-10T20:39:28.883Z [startWithSource] got a stream; getting an audioContext 2017-08-10T20:39:28.887Z [startWithSource] global audio context sample rate: 16000 2017-08-10T20:39:28.887Z [startWithSource] watching sample rate every 5s 2017-08-10T20:39:33.888Z [watchSampleRate] global audio context sample rate: 16000 2017-08-10T20:39:33.892Z [watchSampleRate] new audio context sample rate: 44100 Did this work before? Yes Does this work in other browsers? Yes Chrome version: 60.0.3112.90 Channel: stable OS Version: OS X 10.12.6 Flash Version: This seems to be a problem that is increasing in severity with new versions of Chrome; prior to April, this wasn't an issue we'd ever seen, but since April it's occurred with increasing frequency. It seems to have seen another uptick in frequency with Chrome v60. This occurring in our testing across both Windows and macOS.
,
Aug 10 2017
dalecurtis: Any ideas on this? AFAIK, the audio context just queries the system for the audio output rate so I don't know how the different sample rates of the input mics affect this. I don't have multiple mics at different rates to test this.
,
Aug 11 2017
A little more info: We've built some simple heuristics to infer a data rate from the data flowing out of the microphone. (Ported over from 734290.) In our testing, we attach a ScriptProcessor node to the audio stream; by measuring the time delta between onaudioprocess calls, we can estimate the data sample rate as follows: estimated_sample_rate = node_buffer_length / (time_delta_ms / 1000) For example (with a 44.1kHz mic): estimated_sample_rate = 16384 / (371 / 1000) estimated_sample_rate ~= 44,161 In our testing, this provides a sample rate that is typically within 1% of the correct rate. In cases where Chrome reports the wrong sample rate, the data flowing through the ScriptProcessor remains at the expected sample rate when calculated with the above method.
,
Aug 11 2017
Hmm, it seems like WebAudio is requesting the default rate instead of the rate for a specific device, but I'm not very familiar with this path. +guidou, olka who should know more.
,
Aug 21 2017
@guidou: Friendly ping! Could you please look in this issue. Thank You!
,
Aug 28 2017
Just wanted to update: we've tried rolling users back to an earlier version of Chrome (v56) and this issue disappears immediately. Definitely seems like a regression.
,
Aug 29 2017
,
Sep 12 2017
as per c#6, this is a regression after Chrome 56. give to guidou@ as per dale suggestion.
,
Nov 2 2017
Assigining to grunell@ for further analysis and triage.
,
Jan 9 2018
Assigning to rtoy@ for re-assignment within WebAudio team. It's not clear from the information in the bug where the problem lies, and you'd need to track that down first.
,
Jan 9 2018
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by manoranj...@chromium.org
, Aug 10 2017