Audio output bug since separate audio process release in Chrome 76

[Ben Browitt]

Since the audio separate process [1] release in Chrome 76 we experience audio issues on Windows.

It's hard to reproduce but after starting and stopping mic and webcam randomly on both sides the audio stops playing.

The sender audioInputLevel in webrtc-internals graph is fine but the receiver audioOutputLevel graph is 0.

Refreshing the receiver fixes the issue.

When trying to play a YouTube video after audio fail I sometimes see an error 'Audio renderer error. Please restart your computer.' in the YouTube player.

Is this a known issue?

Is it possible to detect audio failure like YouTube does and ask the user to refresh the page?

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=672469

[Henrik Andreasson]

Please file a bug at https://bugs.chromium.org/p/chromium/issues/list and add as much detail as you can.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/36808372-cf6b-44e4-8cfc-62a9d6eab315%40googlegroups.com.

[Guido Urdaneta]

You can detect failures on a media element (audio or video) by listening to the error event. Once the error event fires, the error attribute of the element will have more information about the error. When the audio process crashes or has some problem, the error code is 3.

On a microphone-backed MediaStreamTrack you can detect failures by listening to the ended event.

Also, like Henrik suggested, file a bug at https://bugs.chromium.org/p/chromium/issues/list

[Ben Browitt]

I've added onerror handler to the video element playing the MediaStream but I'm not getting an error.

After the audio process crash I'm trying to play normal mp4 file in another video element and getting error.code 3 error.message AUDIO_RENDERER_ERROR: audio render error.

videoEl.onerror = function(e) {  console.log('error', e.target.error.code, e.target.error.message); };

There are several issues:

1. The audio process crash when when adding and removing audio and video transceivers randomly or fast enough.

2. A video element with a MediaStream srcObject doesn't fire the error event when the audio process crash.

3. There is no indication in Chrome UI for the audio crash.

[Ben Browitt]

Filed a bug:

https://bugs.chromium.org/p/chromium/issues/detail?id=1001778

[Guido Urdaneta]

On Saturday, September 7, 2019 at 4:16:51 AM UTC+2, Ben Browitt wrote:

I've added onerror handler to the video element playing the MediaStream but I'm not getting an error.

After the audio process crash I'm trying to play normal mp4 file in another video element and getting error.code 3 error.message AUDIO_RENDERER_ERROR: audio render error.

videoEl.onerror = function(e) {  console.log('error', e.target.error.code, e.target.error.message); };

There are several issues:

1. The audio process crash when when adding and removing audio and video transceivers randomly or fast enough.

That looks like a bug. We can continue the discussion about it in the crbug you filed.

 

2. A video element with a MediaStream srcObject doesn't fire the error event when the audio process crash.

You should observe the "ended" event on the MediaStreamTrack.

If the stream does not have an active video track, the element should fire the ended event too, but in Chrome it doesn't due to a bug (https://crbug.com/854991).

 

3. There is no indication in Chrome UI for the audio crash.

There shouldn't be. The audio process starts automatically and immediately upon a crash.

Such crashes in the past were crashes of the whole browser. Now they manifest as standard JS-level events.

[Ben Browitt]

On Sunday, September 8, 2019 at 12:19:37 AM UTC+3, Guido Urdaneta wrote:

On Saturday, September 7, 2019 at 4:16:51 AM UTC+2, Ben Browitt wrote:

I've added onerror handler to the video element playing the MediaStream but I'm not getting an error.

After the audio process crash I'm trying to play normal mp4 file in another video element and getting error.code 3 error.message AUDIO_RENDERER_ERROR: audio render error.

videoEl.onerror = function(e) {  console.log('error', e.target.error.code, e.target.error.message); };

There are several issues:

1. The audio process crash when when adding and removing audio and video transceivers randomly or fast enough.

That looks like a bug. We can continue the discussion about it in the crbug you filed.

 

2. A video element with a MediaStream srcObject doesn't fire the error event when the audio process crash.

You should observe the "ended" event on the MediaStreamTrack.

If the stream does not have an active video track, the element should fire the ended event too, but in Chrome it doesn't due to a bug (https://crbug.com/854991).

Observing "ended" event to detect audio process failure seems weird. Tracks might end for normal reasons. Isn't there an error when can listen to?

 

3. There is no indication in Chrome UI for the audio crash.

There shouldn't be. The audio process starts automatically and immediately upon a crash.

Such crashes in the past were crashes of the whole browser. Now they manifest as standard JS-level events.

YouTube show a message:

Audio renderer error. Please restart your computer.

If there is unrecoverable error, I would expect the browser to let the users know and tell them how to solve it.

In a WebRTC app, there isn't even a way to detect the error.

[Guido Urdaneta]

On Sunday, September 8, 2019 at 9:37:25 PM UTC+2, Ben Browitt wrote:

On Sunday, September 8, 2019 at 12:19:37 AM UTC+3, Guido Urdaneta wrote:

On Saturday, September 7, 2019 at 4:16:51 AM UTC+2, Ben Browitt wrote:

I've added onerror handler to the video element playing the MediaStream but I'm not getting an error.

After the audio process crash I'm trying to play normal mp4 file in another video element and getting error.code 3 error.message AUDIO_RENDERER_ERROR: audio render error.

videoEl.onerror = function(e) {  console.log('error', e.target.error.code, e.target.error.message); };

There are several issues:

1. The audio process crash when when adding and removing audio and video transceivers randomly or fast enough.

That looks like a bug. We can continue the discussion about it in the crbug you filed.

 

2. A video element with a MediaStream srcObject doesn't fire the error event when the audio process crash.

You should observe the "ended" event on the MediaStreamTrack.

If the stream does not have an active video track, the element should fire the ended event too, but in Chrome it doesn't due to a bug (https://crbug.com/854991).

Observing "ended" event to detect audio process failure seems weird. Tracks might end for normal reasons. Isn't there an error when can listen to?

The audio process is just an implementation detail of Chrome. It's not part of the Web platform.

The ended event on a track is fired (according to the spec) whenever a track is stopped for any reason other than a call to the stop() event.

That reason can be anything, a user disconnecting the hardware or an internal issue with the implementation (e.g., audio process crash, or OS APIs returned an error for some reason, or anything else).

 

 

3. There is no indication in Chrome UI for the audio crash.

There shouldn't be. The audio process starts automatically and immediately upon a crash.

Such crashes in the past were crashes of the whole browser. Now they manifest as standard JS-level events.

YouTube show a message:

Audio renderer error. Please restart your computer.

If there is unrecoverable error, I would expect the browser to let the users know and tell them how to solve it.

In a WebRTC app, there isn't even a way to detect the error.

I think you are mislead about the youtube message.

An audio process restart is not an unrecoverable error. If you reload the youtube page that shows that message (or try to play any other video) it will play without problem. No need to restart the browser.

YouTube seems to attempt to continue playing after one rendering error, but after more than one error it assumes that it is a more serious problem and provides that recommendation of restarting the browser.

There might be some cases where the best course of action for this type of error is (or used to be) to restart the browser.

However, a crash of the audio process (which used to be a crash of the whole browser before the audio process) is definitely not an unrecoverable error for which there should be some UI.

In general, after a crash, the audio process restarts automatically and is ready to play audio right away.

Such crashes are observed in JavaScript as standard Web Platform events that are allowed by the specs when internal problems occur. An application can handle those events (or not) according to any policy it deems appropriate.

[Ben Browitt]

On Monday, September 9, 2019 at 11:40:53 PM UTC+3, Guido Urdaneta wrote:

On Sunday, September 8, 2019 at 9:37:25 PM UTC+2, Ben Browitt wrote:

On Sunday, September 8, 2019 at 12:19:37 AM UTC+3, Guido Urdaneta wrote:

On Saturday, September 7, 2019 at 4:16:51 AM UTC+2, Ben Browitt wrote:

I've added onerror handler to the video element playing the MediaStream but I'm not getting an error.

After the audio process crash I'm trying to play normal mp4 file in another video element and getting error.code 3 error.message AUDIO_RENDERER_ERROR: audio render error.

videoEl.onerror = function(e) {  console.log('error', e.target.error.code, e.target.error.message); };

There are several issues:

1. The audio process crash when when adding and removing audio and video transceivers randomly or fast enough.

That looks like a bug. We can continue the discussion about it in the crbug you filed.

 

2. A video element with a MediaStream srcObject doesn't fire the error event when the audio process crash.

You should observe the "ended" event on the MediaStreamTrack.

If the stream does not have an active video track, the element should fire the ended event too, but in Chrome it doesn't due to a bug (https://crbug.com/854991).

Observing "ended" event to detect audio process failure seems weird. Tracks might end for normal reasons. Isn't there an error when can listen to?

The audio process is just an implementation detail of Chrome. It's not part of the Web platform.

The ended event on a track is fired (according to the spec) whenever a track is stopped for any reason other than a call to the stop() event.

That reason can be anything, a user disconnecting the hardware or an internal issue with the implementation (e.g., audio process crash, or OS APIs returned an error for some reason, or anything else).

Exactly, the reason may be anything so I don't know how to tell if the remote user stopped sending data normally (BYE?) or if  there is a local issue with the audio.

Is there a way to tell if there is an audio error?

[Guido Urdaneta]

Note that remote tracks are not affected by problems with the local audio stack, so they are not ended if the audio process restarts.

Local tracks (i.e., from the microphone) are.