When an user clicks the mute button, it seems like it muted the other user

[b4oshany]

In addition, this issue seems to be only happening on IOs to IOs connection. I tested it using Windows and Android, and it worked how it suppose to. Tim's demo version of the code also has this bug.

[b4oshany]

After install remotedebug-ios-webkit-adapter, which allows Chrome on Windows 10 to debug Safari on IOs, I discovered that the mute button on the iPhone is somehow muting the remote audio stream. My assumption is, the localStream and the remoteStream got mixed up during the variable assignment process.

Funnily, this only happens on iOS.

[b4oshany]

This issue only happens when something is in the buffer. @steely-glint

[b4oshany]

@bverbol and @steely-glint It seems like this is a known issue according to https://bugs.webkit.org/show_bug.cgi?id=180748

iOS Safe Audio Context is a possible fix for the drop of frames for the audio context.

[b4oshany]

Currently, there's a background task running which tries to reconnect the AudioContext with the buffer. This works most of the times.

    setInterval(function(){
        if(isCallActive){
            if(unruptEnabled && remoteBuffSample.sum == 0){
                resumeBuffer();
                document.getElementById('out').muted = false;
                $("#unruptToggle").attr("disabled", "disabled");
            }else if (unruptEnabled) {
                document.getElementById('out').muted = true;
                $("#unruptToggle").removeAttr("disabled");
            }else{
                $("#unruptToggle").removeAttr("disabled");
            }
        }
    }, 1000);

The remoteBuffSample.sum equals to 0 when the remote microphone is muted or buffer is disconnected,

[steely-glint]

I noticed this quite early on - and I tried to work around it by putting all the AudioNodes into the global scope, based on the theory that javascript was garbage collecting them when (incorrectly) thought they were no longer in scope.

The other thing to look at is a change @danjenkins to allow remote mute by sending a message over the rendezvous server.

[b4oshany]

Firstly, the remote side is not muted. If you do document.getElementById('out').muted = false; in the console, you'll hear the remote sound. It's the buffer for the audio context is lost. The resumeBuffer is as the following:

    resumeBuffer = () => {
        console.log("Connecting AudioContext to buffer");
        node.connect(buffer);
        isNodeConnected = true;
        document.getElementById('out').muted = true;
        yourac.resume().then(() => {
            console.log('Playback resumed successfully');
        });
    };

This resumes the normal playback for the first 4 times if the buffer for the audio context is lost. However, after those 4 times, the resumeBuffer function stop works (only on phones above iPhone SE. @bverbol found an article that verifies that this is happening on iPhone 8 after re-establishing the buffer after 4 times.

[steely-glint]

Ah, so it's a bug in ios Safari doing muted? If so, an ugly work-around you could do, would be to do the mute/unmute in the buffer code rather than on the html element. So just multiply the audio values by 0.0 when they should be muted.

[bverbol]

thanks tim and yes I approve of implementing our own mute function. i was wondering would this also enable us to put up a warning dialog and or tone when speaking on mute? i have also just realised it would be nice for that dialog to also be enhanced when we can save near buffers, to invite the user to record an aside if a thought occurs on a different topic to the call... so in that case we would be muting the onward transmission but still filling the near buffer in order to save it as an utterance recording and possibly play it into the call later on a change of subject, so what we do should be compatible with that future use case please. Best wishes from Brian Reynolds May good will enable us to improve what we can, accept what we cant, converse with all who might help, so we cooperate in peace for the benefit of all, and assist those in need.

…

On 29 May 2018 at 15:36, Tim Panton ***@***.***> wrote: Ah, so it's a bug in ios Safari doing muted? If so, an ugly work-around you could do, would be to do the mute/unmute in the buffer code rather than on the html element. So just multiply the audio values by 0.0 when they should be muted. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/Unrupt/unrupt-demo/issues/11#issuecomment-392934773>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADQTPnelo_v9rQ4yD9LajI__VoAcp7HCks5t3bFYgaJpZM4T5RcP> .

[b4oshany]

Well, even if we do develop our own muting function. It does not solve the problem at hand, which is the loss of the buffer for the audio context. This bug was present before I started the project and even without the mute button being clicked, for example, Brian used to tell me to refresh because we lost the AudioContext. It's not the AudioContext we lost, it was the buffer for the AudioContext, especially since the sample rate for the above context equals or greater than 44100 (default rate). However, after the merge of Tim's and David's versions with some additional tweaking, seems to happen only when the mute button is clicked.