Issue metadata
Sign in to add a comment
|
getUserMedia() with explicit deviceId yields silent audio track with BT headsets on CrOS every 2nd time
Reported by
thembr...@gmail.com,
May 23 2018
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36 Platform: 10682.0.0 (Official Build) dev-channel kevin Steps to reproduce the problem: 1. Open https://output.jsbin.com/hobuhi on CrOS with a BT headset connected 2. If sources is empty, click 'get stream' version, grant access and re-load page. 3. Select bluetooth headset in dropdown explicitly (NOT via default input) 4. Click on 'get stream' and watch console log for 'hasAudio' messages What is the expected behavior? Audio streams should contain audio data consistently. What went wrong? Audio stream is silent / does not contain any data on exactly every second attempt it is acquired. It does not matter if the page is re-loaded in-between. Did this work before? Yes 64 (did not verify) Does this work in other browsers? Yes Chrome version: 68.0.3431.0 Channel: dev OS Version: Flash Version: The demo uses the web audio API, however this not a WebAudio issue, feeding the stream into MediaRecorder instead of the WebAudioAPI shows the same symptoms (recorder never yields any data when stream is 'silent'). Model of BT headset does not seem to matter, reproduces on all I tried (e.g. Airpods). Source is here: https://jsbin.com/hobuhi/edit?html,js
,
Jun 4 2018
Patrik, can someone from your team help us reproduce and confirm this bug, please?
,
Jun 5 2018
Wow, that is an exotic bug. Ravi, Vasan, can you shoehorn this one in during your CrOS test passes? Marina, what logs do you want if they repro?
,
Jun 5 2018
Sure we will get reproduced with our test environment.
,
Jun 5 2018
Thank you. Audio traces would be useful, from chrome://tracing, and PeerConnection updates and stats data, from chrome://webrtc-internals. Guido, anything else that might be useful?
,
Jun 5 2018
For now, that should be enough. The most important thing would be to be able to reproduce it.
,
Jun 5 2018
Hi all, we have reproduced the issue on M68 68.0.3440.4. Kindly find the logs in this link: https://cloud.google.com/console/storage/chromiumos-test-logs/bugfiles/cr/845880/ We will reproduce this issue in M64 or older version to confirm if this is a regression. We will also add this test in our smoke test suite.
,
Jun 5 2018
This issue is reproducible in M64 64.0.3283.190 in Kevin. Thus, It can be a old bug. This issue is reproducible in Santa device as well. It is not a device specific issue.
,
Jun 5 2018
Can you try on another platform just to confirm that it's a platform-specific bug?
,
Jun 5 2018
@Guid: I have tried to reproduce this issue in Macbook Pro 15" and windows 10 Asus UX32A. It works as intended. I don't have bluetooth dongle to check in Linux work station. I will update here as soon I get one. Thus a crOS specific as of now.
,
Jun 19 2018
Switching component to OS>Kernel>Audio since this is CrOS specific. Please switch the component back if this turns out to be incorrect. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by guidou@chromium.org
, May 24 2018