New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 669510 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jan 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Feature



Sign in to add a comment

Logging/stats for when using ALSA in a WebRTC call

Project Member Reported by peah@chromium.org, Nov 29 2016

Issue description

On Linux, the default behavior for a WebRTC call is to first open the pulse audio interface. If that fails, the ALSA audio interface is instead opened.

There should be stats that monitor when this happens, as the pulse interface is considered more stable than the ALSA interface, and hence the choice of interface may be related to any audio issues.

Apart from stats, this should be logged as well.

 

Comment 1 by guidou@chromium.org, Nov 29 2016

Owner: olka@chromium.org
My understanding is that the ALSA interface is no longer maintained.
olka@: can you confirm?

Comment 2 by olka@chromium.org, Nov 29 2016

Cc: olka@chromium.org
Owner: grunell@chromium.org
grunell@ and peah@ just observed the case when there was fall over to alsa
Labels: M-57
Tagging with current canary milestone.Please change accordingly if needed.
Cc: solenberg@chromium.org
Components: Internals>Media>Audio
Status: Assigned (was: Unconfirmed)
The ALSA interface is maintained, and we fall back on it if PulseAudio fails to initialize.

We already have stats that show what audio system is used (Media.LinuxAudioIO), but we don't know the rate of PulseAudio init failure.

Furthermore, this information should be in the WebRTC log and I'm working on a CL for that.
The background for doing this is glitch problems that can go away if Chrome is restarted. peah@ experienced glitches and the trace showed that ALSA was used. One theory I have is that it happens when ALSA is used, and restarting gets the user back to PulseAudio. Regardless, it's good info to have.
Project Member

Comment 6 by bugdroid1@chromium.org, Dec 2 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/12d3f1b37dbe91316f5c3ce2bfc006204458fe8d

commit 12d3f1b37dbe91316f5c3ce2bfc006204458fe8d
Author: grunell <grunell@chromium.org>
Date: Fri Dec 02 12:28:10 2016

Log audio system used to WebRTC log.

This is interesting on for example Linux, where we fallback on ALSA if PulseAudio fails to initialize.

* Add AudioManager::GetName() and implementations in sub-classes.
* Log it to WebRTC log in WebRtcTextLogHandler::LogInitialInfoOnIOThread().

BUG= 669510 

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2538793002
Cr-Commit-Position: refs/heads/master@{#435923}

[modify] https://crrev.com/12d3f1b37dbe91316f5c3ce2bfc006204458fe8d/chrome/browser/media/webrtc/webrtc_text_log_handler.cc
[modify] https://crrev.com/12d3f1b37dbe91316f5c3ce2bfc006204458fe8d/chromecast/media/audio/cast_audio_manager.cc
[modify] https://crrev.com/12d3f1b37dbe91316f5c3ce2bfc006204458fe8d/chromecast/media/audio/cast_audio_manager.h
[modify] https://crrev.com/12d3f1b37dbe91316f5c3ce2bfc006204458fe8d/media/audio/alsa/audio_manager_alsa.cc
[modify] https://crrev.com/12d3f1b37dbe91316f5c3ce2bfc006204458fe8d/media/audio/alsa/audio_manager_alsa.h
[modify] https://crrev.com/12d3f1b37dbe91316f5c3ce2bfc006204458fe8d/media/audio/android/audio_manager_android.cc
[modify] https://crrev.com/12d3f1b37dbe91316f5c3ce2bfc006204458fe8d/media/audio/android/audio_manager_android.h
[modify] https://crrev.com/12d3f1b37dbe91316f5c3ce2bfc006204458fe8d/media/audio/audio_manager.h
[modify] https://crrev.com/12d3f1b37dbe91316f5c3ce2bfc006204458fe8d/media/audio/audio_output_proxy_unittest.cc
[modify] https://crrev.com/12d3f1b37dbe91316f5c3ce2bfc006204458fe8d/media/audio/cras/audio_manager_cras.cc
[modify] https://crrev.com/12d3f1b37dbe91316f5c3ce2bfc006204458fe8d/media/audio/cras/audio_manager_cras.h
[modify] https://crrev.com/12d3f1b37dbe91316f5c3ce2bfc006204458fe8d/media/audio/fake_audio_manager.cc
[modify] https://crrev.com/12d3f1b37dbe91316f5c3ce2bfc006204458fe8d/media/audio/fake_audio_manager.h
[modify] https://crrev.com/12d3f1b37dbe91316f5c3ce2bfc006204458fe8d/media/audio/mac/audio_manager_mac.cc
[modify] https://crrev.com/12d3f1b37dbe91316f5c3ce2bfc006204458fe8d/media/audio/mac/audio_manager_mac.h
[modify] https://crrev.com/12d3f1b37dbe91316f5c3ce2bfc006204458fe8d/media/audio/mock_audio_manager.cc
[modify] https://crrev.com/12d3f1b37dbe91316f5c3ce2bfc006204458fe8d/media/audio/mock_audio_manager.h
[modify] https://crrev.com/12d3f1b37dbe91316f5c3ce2bfc006204458fe8d/media/audio/pulse/audio_manager_pulse.cc
[modify] https://crrev.com/12d3f1b37dbe91316f5c3ce2bfc006204458fe8d/media/audio/pulse/audio_manager_pulse.h
[modify] https://crrev.com/12d3f1b37dbe91316f5c3ce2bfc006204458fe8d/media/audio/win/audio_manager_win.cc
[modify] https://crrev.com/12d3f1b37dbe91316f5c3ce2bfc006204458fe8d/media/audio/win/audio_manager_win.h

Is this finished now?
Status: Fixed (was: Assigned)
I took a look at when USE_PULSEAUDIO and USE_ALSA is defined. USE_PULSEAUDIO is always defined when USE_ALSA is, if not USE_CRAS is defined and platform is not Chromecast. So, for platform "Linux" in UMA stats, USE_PULSEAUDIO is always defined. In the Media.LinuxAudioIO stats for platform Linux, if Alsa is used it means PulseAudio has tried to init and failed.

(USE_CRAS is only defined for Chrome OS.) 

https://cs.chromium.org/chromium/src/media/media_options.gni?sq=package:chromium&dr=C&l=64

Code for creating AudioManagers (including falling back on Alsa):

https://cs.chromium.org/chromium/src/media/audio/linux/audio_manager_linux.cc?l=30

This means there is enough information in the stats as it is, and we now have information in the log too.

Sign in to add a comment