bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Investigate libcubeb backend initialization failures reported via AUDIOSTREAM_BACKEND_USED telemetry

RESOLVED FIXED in Firefox 50

Status

()

Core
Audio/Video: cubeb
P2
normal
Rank:
21
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: kinetik, Unassigned)

Tracking

Trunk
mozilla50
Points:
---

Firefox Tracking Flags

(firefox50 fixed)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Paul added telemetry to report the libcubeb backend in bug 1280630.  We're getting some data for that now, and I noticed that bucket 13 (CUBEB_BACKEND_INIT_FAILURE_OTHER) is unusually high at ~1.2% of all reports.

It looks like it might make sense to add something like AUDIOSTREAM_FAILURE_REASON to narrow down *why* we're seeing so many failures... we may need to audit and improve the error reporting out of our libcubeb backends richer first.
# Linux
PulseAudio is 95%
Alsa is 5%
Error rate is minimal (less than 0.01% for initial and subsequent failure)

# OSX
No errors

# Windows
## Accross all versions
WASAPI is 97.5%
WinMM is 1.31%
0.03% of failures occur when trying to open a stream for the first time
1.24% of failures occur after opening a stream sucessfuly

## When removing XP
WASAPI is 98.58%
WinMM is 0.15%
0.03% of failure the first time
1.25% of failure when having previously opened a stream

## Only Windows XP
WASAPI is 1.87%. Not sure how this is possible
WinMM is 98.98%
Failure to open a stream for the first time is 0.06%
No failures the rest of the time

## Windows 2000 and Windows Vista
No data

## Only Vista+
WASAPI is 98.58%
WinMM is 0.15%
0.03% of failures when opening a stream for the first time
1.25% otherwise
I think the data is skewed by the fact that a MediaStreamGraph that needs to output audio and fails to open an audio stream will fall back to a normal thread, but will try to re-open an audio stream every 10ms until it succeeds or the graph stops.

I'll write some code to not over-report this.
Created attachment 8775125 [details]
Bug 1289678 - Don't count audio stream creation failures when retrying on Telemetry.

When failing to create an audio stream, we fallback to a SystemClockDriver
marked as being a "fallback driver". When failing again to open an audio stream
after re-trying, we can check whether we came from a fallback driver, and not
report the failure again to telemetry.

Review commit: https://reviewboard.mozilla.org/r/67408/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/67408/
Attachment #8775125 - Flags: review?(kinetik)

Updated

2 years ago
Rank: 21
Priority: -- → P2
(Reporter)

Comment 4

2 years ago
Comment on attachment 8775125 [details]
Bug 1289678 - Don't count audio stream creation failures when retrying on Telemetry.

https://reviewboard.mozilla.org/r/67408/#review64696
Attachment #8775125 - Flags: review?(kinetik) → review+

Comment 5

2 years ago
Pushed by paul@paul.cx:
https://hg.mozilla.org/integration/mozilla-inbound/rev/58f01ab6d856
Don't count audio stream creation failures when retrying on Telemetry. r=kinetik

Comment 6

2 years ago
Pushed by paul@paul.cx:
https://hg.mozilla.org/integration/mozilla-inbound/rev/0b81459b4802
Fix warning as errors on a CLOSED TREE.

Comment 7

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/58f01ab6d856
https://hg.mozilla.org/mozilla-central/rev/0b81459b4802
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox50: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
You need to log in before you can comment on or make changes to this bug.