In Progress
Status Update
No update yet.
Comments
da...@chromium.org
[Empty comment from Monorail migration]
[Monorail components: Internals>Media>Audio]
[Monorail components: Internals>Media>Audio]
da...@chromium.org
Summary of our UMA metrics:
Media.AudioOutputController.CallbackError: ~0% of errors.
Media.AudioRendererImpl.SinkStatus: ~0.02% encounter internal error (but this should only be due to ~AudioOutputDevice)
Media.FallbackToHighLatencyAudioPath: ~0.5% end up using WaveOut API.
Media.AudioOutputControllerPlaybackStartupSuccess : ~0.02% of streams never receive audio callbacks 5 seconds after stream start.
@strobe: Does YT record AUDIO_RENDERER_ERROR only based on the MediaElement.error code or is it also recorded for streams that never advance current time?
Media.AudioOutputController.CallbackError: ~0% of errors.
Media.AudioRendererImpl.SinkStatus: ~0.02% encounter internal error (but this should only be due to ~AudioOutputDevice)
Media.FallbackToHighLatencyAudioPath: ~0.5% end up using WaveOut API.
Media.AudioOutputControllerPlaybackStartupSuccess : ~0.02% of streams never receive audio callbacks 5 seconds after stream start.
@strobe: Does YT record AUDIO_RENDERER_ERROR only based on the MediaElement.error code or is it also recorded for streams that never advance current time?
va...@gmail.com
>Windows users/day hitting some form of audio playback error.
The only time I was hitting this problem is
a) very bad Nvidia HD audio driver since like 20 releases ago, that always crashes, but switching the device & driver on and off fixes the issue
b) exclusive rendering. If Atmos is being rendered in the background, there is no way for other sound sources to play. That is just the way it is and works as espected as there is no way to decode Atmos AND then mix the other sound inside it.
The only time I was hitting this problem is
a) very bad Nvidia HD audio driver since like 20 releases ago, that always crashes, but switching the device & driver on and off fixes the issue
b) exclusive rendering. If Atmos is being rendered in the background, there is no way for other sound sources to play. That is just the way it is and works as espected as there is no way to decode Atmos AND then mix the other sound inside it.
st...@google.com
AUDIO_RENDERER_ERROR comes straight from the media element, and is presented as a fatal error (if it persists over a retry cycle). An error screen is shown which explicitly says "Audio renderer error."
https://www.drivereasy.com/knowledge/fixed-youtube-audio-renderer-error-on-windows-10
We do record (different) errors if it takes longer than expected to advance media time, with debugging information and a counterfactual watchdog, but we think that in most cases on Chrome currently those failures to advance are intentional.
We do record (different) errors if it takes longer than expected to advance media time, with debugging information and a counterfactual watchdog, but we think that in most cases on Chrome currently those failures to advance are intentional.
da...@chromium.org
Thanks. That means adding the HRESULT logging in WASAPI output is a good start. Will do that this week.
da...@chromium.org
[Empty comment from Monorail migration]
[Deleted User] <[Deleted User]>
da...@chromium.org
[Empty comment from Monorail migration]
[Deleted User] <[Deleted User]>
gi...@appspot.gserviceaccount.com
The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src/+/7f1f94956ed3ea90b9d75d2a26b899532cb1ab37
commit 7f1f94956ed3ea90b9d75d2a26b899532cb1ab37
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Mon May 17 21:03:13 2021
Log HRESULT failures during Windows audio output.
This will help diagnose failures at the output stage which may
be affecting audio renderer playback errors.
R=henrika
Bug: 1196874
Change-Id: I7ca73305fb6e0fe01056518a200f4881dfe711b9
Reviewed-on:https://chromium-review.googlesource.com/c/chromium/src/+/2898468
Auto-Submit: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Henrik Andreasson <henrika@chromium.org>
Reviewed-by: Brian White <bcwhite@chromium.org>
Commit-Queue: Brian White <bcwhite@chromium.org>
Cr-Commit-Position: refs/heads/master@{#883612}
[modify]https://crrev.com/7f1f94956ed3ea90b9d75d2a26b899532cb1ab37/media/audio/win/audio_low_latency_output_win.cc
[modify]https://crrev.com/7f1f94956ed3ea90b9d75d2a26b899532cb1ab37/tools/metrics/histograms/histograms_xml/media/histograms.xml
commit 7f1f94956ed3ea90b9d75d2a26b899532cb1ab37
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Mon May 17 21:03:13 2021
Log HRESULT failures during Windows audio output.
This will help diagnose failures at the output stage which may
be affecting audio renderer playback errors.
R=henrika
Bug: 1196874
Change-Id: I7ca73305fb6e0fe01056518a200f4881dfe711b9
Reviewed-on:
Auto-Submit: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Henrik Andreasson <henrika@chromium.org>
Reviewed-by: Brian White <bcwhite@chromium.org>
Commit-Queue: Brian White <bcwhite@chromium.org>
Cr-Commit-Position: refs/heads/master@{#883612}
[modify]
[modify]
da...@chromium.org
[Empty comment from Monorail migration]
gi...@appspot.gserviceaccount.com
The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src/+/338e019535ec4a6614a6d862bc5064c067fe992c
commit 338e019535ec4a6614a6d862bc5064c067fe992c
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Mon May 17 23:07:02 2021
Fix accidentally expired histogram. Add more owners.
This histogram was accidentally left to expire since the owner
left the Chromium project. Add more owners and unexpire. These
should never expire since they are audio pipeline health
metrics.
Bug: 1196874
Change-Id: Ibd093652012e3baae4e43c1e102e9f10d21b7d53
Reviewed-on:https://chromium-review.googlesource.com/c/chromium/src/+/2898461
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Caitlin Fischer <caitlinfischer@google.com>
Cr-Commit-Position: refs/heads/master@{#883693}
[modify]https://crrev.com/338e019535ec4a6614a6d862bc5064c067fe992c/tools/metrics/histograms/histograms_xml/media/histograms.xml
commit 338e019535ec4a6614a6d862bc5064c067fe992c
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Mon May 17 23:07:02 2021
Fix accidentally expired histogram. Add more owners.
This histogram was accidentally left to expire since the owner
left the Chromium project. Add more owners and unexpire. These
should never expire since they are audio pipeline health
metrics.
Bug: 1196874
Change-Id: Ibd093652012e3baae4e43c1e102e9f10d21b7d53
Reviewed-on:
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Caitlin Fischer <caitlinfischer@google.com>
Cr-Commit-Position: refs/heads/master@{#883693}
[modify]
da...@chromium.org
Just canary data, but the biggest HR that shows up across all categories so far is AUDCLNT_E_DEVICE_INVALIDATED. Perhaps we should route these as OnDeviceChanged() instead of errors?
Our expectation is that IAudioSessionEvents notifications should be processed before we receive a AUDCLNT_E_DEVICE_INVALIDATED from some random call and that any subsequent errors are suppressed by the OutputController. That said, we use BindToCurrentLoop() for the notifications so I think it's possible that we get an error before we handle the invalidation.
da...@chromium.org
Actually those are still suppressed since all non-device change errors are deferred for 1 second.
he...@chromium.org
he...@chromium.org
0x88890004 - AUDCLNT_E_DEVICE_INVALIDATED
da...@chromium.org
Yeah that sequence is expected, it doesn't matter unless the error is seen by the OutputController -- which per c#13 defers errors for 1 second and cancels them if a device change comes in within that time frame.
da...@chromium.org
@rafael: Do you have any idea what the 14007 HRESULT value is returned for? It's dominating failures during Open().
ra...@microsoft.com
0:000> !error 36B7
Error code: (Win32) 0x36b7 (14007) - The requested lookup key was not found in any active activation context.
Error code: (Win32) 0x36b7 (14007) - The requested lookup key was not found in any active activation context.
wi...@microsoft.com
[Empty comment from Monorail migration]
st...@meta.com
Facebook is also seeing this error, almost exclusively from Chrome/Windows users. Please let us know if we can assist the investigation in any way.
he...@chromium.org
It could be that we log results from GetLastError when the real issue was not a Core Audio API issue. See e.g. [1] which differs from [2] where we know that a Core Audio API has failed. It might be a good idea to try to narrow down where exactly in Open() 14007 comes from. See also [3].
[1]https://source.chromium.org/chromium/chromium/src/+/main:media/audio/win/audio_low_latency_output_win.cc;l=195;drc=079df01a818160c3505370d1a5290c2e94bf8788
[2]https://source.chromium.org/chromium/chromium/src/+/main:media/audio/win/audio_low_latency_output_win.cc;l=216;drc=079df01a818160c3505370d1a5290c2e94bf8788
[3]https://stackoverflow.com/questions/20943103/loadlibrary-fails-with-error-code-14007
[1]
[2]
[3]
da...@chromium.org
Attaching the latest percentages from:
https://uma.googleplex.com/p/chrome/histograms?sid=8531297221c204640c57b6e303013360
Will see about adding more instrumentation to Open along the lines Henrik suggested. We seem to see about 0.02% of streams ending up on the fake audio path due to Open() failures.
Will see about adding more instrumentation to Open along the lines Henrik suggested. We seem to see about 0.02% of streams ending up on the fake audio path due to Open() failures.
tg...@chromium.org
[Empty comment from Monorail migration]
[Deleted User] <[Deleted User]>
tg...@chromium.org
da...@chromium.org
[Empty comment from Monorail migration]
da...@chromium.org
This is coming up again on https://uma.googleplex.com/p/chrome/timeline_v2/?sid=770d07e3a9a5d3926188a6618daccdba
I wonder if it makes sense to make some tactical changes here:
- Add retries somewhere along the stack for Create/Open failures (we kind of do this with WaveOut fallback, but we'd like to delete that path...)
- Treat all first time AudioSourceCallback::OnError calls as device changes.
I wonder if it makes sense to make some tactical changes here:
- Add retries somewhere along the stack for Create/Open failures (we kind of do this with WaveOut fallback, but we'd like to delete that path...)
- Treat all first time AudioSourceCallback::OnError calls as device changes.
st...@google.com
Worth noting that the YT player already retries this (by waiting a short time, getting a new media element, attaching a new Media Source, and appending fresh media) at least once before failing.
da...@chromium.org
Ah thanks for the context. That should retry the whole process with the default device id. We don't reuse sinks with errors (but there have been bugs around this in the past).
I know some older desktop devices don't even report a audio device if the headphone jack is unplugged -- likewise a system with USB only audio would do the same. In those cases the error would be permanent. We fall back to fake audio in some cases here, but probably we don't catch all of them.
We could try treating all errors as an external mute event instead to keep playback going and hope that when the user later unmutes they have plugged a device in.
I know some older desktop devices don't even report a audio device if the headphone jack is unplugged -- likewise a system with USB only audio would do the same. In those cases the error would be permanent. We fall back to fake audio in some cases here, but probably we don't catch all of them.
We could try treating all errors as an external mute event instead to keep playback going and hope that when the user later unmutes they have plugged a device in.
is...@google.com
This issue was migrated from crbug.com/chromium/1196874?no_tracker_redirect=1
[Monorail components added to Component Tags custom field.]
[Monorail components added to Component Tags custom field.]
Description
YouTube receives hundreds of reports per day from users who complain that video plays without audio on Desktop Web. 95% of reports come from Windows users, almost all are on Chrome. We believe there are three main causes:
- User error: A user may inadvertently put YouTube into a muted state.
- OS Issues: Accidental device fall over falls into this category of error; for example, if the user has 2x DP/HDMI monitors w/ only 1 audio connection, the output device may change between the two.
- Driver issues: 1st or 3rd party drivers can cause audio output to hang. Of course, Windows is the only consumer desktop OS with ODM integration. Higher rates of peripheral connection (HDMI monitors with independent volume, USB sound cards, etc.) creates additional ways for audio to fail. We propose that YouTube and Microsoft collaborate on driver testing and bug fixing moving forward and investigate existing issues.
This is an umbrella tracking bug for efforts around this problem.