Firefox 68 audio muted problem with Safari

[Ivan]

Hi,

I'm experiencing an audio issue when using Firefox 68 and Safari.
This problem is reproducible using AppRTC https://appr.tc/

1. User A joins a room using Firefox 68.
2. User A mute video and audio using the buttons in the UI.
3. User B joins the same room using Safari.
4. User A un-mute audio.

Expected behaviour:

User B (Safari) can hear the audio from User A (Firefox 68).

Actual behaviour:

User B (Safari) can't hear the audio from User A (Firefox 68) until User A (Firefox 68) enables the video.

Does anyone know what could be the issue?

Could be related to audio - video synchronization?
There were some changes in Firefox 68 related with this.
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/68

This problem doesn't appear in earlier Firefox versions.

Thanks!

Ivan

[Byron Campen]

    I just tried this out, and Firefox does seem to be sending audio RTP continuously to Safari. When muted, the packets are much smaller, which I am guessing are silence. The same thing seems to happen with Firefox/Firefox. I am guessing that appr.tc is simply not attaching the remote streams to something that will render them until video is unmuted on the other side, but whatever the cause this looks like an appr.tc issue.

Best regards,

Byron Campen

--

---
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/d98b356c-fb4d-44c4-a8a0-a4d0c4f715f9%40googlegroups.com.

[Nils Ohlmeier]

I can repro this as well. But not only on appr.tc, but on appear.in as well. Plus the the same problem exists if I replace Firefox with Chrome.

But the issue does not reproduce for me between Chrome and Firefox. So to me this looks like some Safari bug.

Best

  Nils Ohlmeier

[Ivan]

Hi,

Thanks for your replies Byron and Nils :)

The thing is, if I use an earlier version of Firefox (e.g. Firefox 67), I can't reproduce this behaviour.
So it seems that something has changed in Firefox 68, but I can't find what it is.

Also, I just realized that the same problem exists if User B uses Chromium/Chrome.
So it seems that it's not only a problem in Safari.

Regards,
Ivan

[Ivan]

There is a way to work around the problem when User B uses Chromium/Chrome.

After these steps:

1. User A joins a room using Firefox 68.
2. User A mute video and audio using the buttons in the UI.

3. User B joins the same room using Chromium/Chrome.

4. User A un-mute audio.

User B opens Chromium/Chrome console, creates an audio element and attaches the stream from User A video element to the audio element:

var remoteAudioElement = document.createElement('audio')
remoteAudioElement.setAttribute('id', 'remote-audio')
remoteAudioElement.toggleAttribute('autoplay')
document.body.appendChild(remoteAudioElement)
document.getElementById('remote-audio').srcObject = document.getElementById('remote-video').srcObject

After this, User B can hear User A.

So it seems that it is something related with audio and video sync, since just an audio element can render the incoming audio.
But if the stream is rendered by a video element, no audio is played.

This sadly is only a workaround for Chromium/Chrome but it doesn't work on Safari :/

Also, I'm still wondering why this only occurs when using Firefox 68 and not with earlier Firefox versions.

Regards,

Ivan

[Philipp Hancke]

What is the video width/height displayed in chrome://webrtc-internals before/after unmuting? Looks like constant 0 to me.

Video elements can't play audio if they have video but can not fire loadedmetadata which includes the size.

--

---
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/7ee039f5-920e-4d97-87c8-a259ed5fafe8%40googlegroups.com.

[Byron Campen]

    In that case, we could use mozregression and pinpoint the change that is causing the problem.

Best regards,

Byron Campen

--

---
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/7512bcd5-348f-40b2-be9c-fc3f460f3c54%40googlegroups.com.

[Ivan]

That seems to be the problem.

Firefox 68 doesn't transmit any video (not even the metadata of the video) when the video is disabled.
As Philipp said, this makes 'loadedmetadata' not being triggered by the video element, so no sound is played.

The "audio element workaround" works on Chromium/Chrome since the audio element doesn't seem to wait for any video metada to start playing the sound.
But on Safari it seems that the audio element still waits for the video metadata to trigger 'loadedmetadata' (and then start playing the sound).

This issue is not reproducible using older Firefox versions, since in these versions a "black video" stream is transmited even when the video is disabled.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.

[Philipp Hancke]

yes, that triggered some discussion in the #media channel on irc.mozilla.org and the culprit was found relatively quickly. See https://bugzil.la/1570673

Good catch!

That this is still an issue in Safari might depend on a behaviour fix in blink which isn't in webkit... I think this was https://bugs.chromium.org/p/chromium/issues/detail?id=403710

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/eeb84cb4-fc95-4e78-9081-1f92a88b7816%40googlegroups.com.

[Philipp Hancke]

what you might try is something that helped in old Chrome versions: create a separate audio element and attach a new mediastream consisting of the audio elements tracks.