936034 - Sound is distorted on one side on 1:1 call

Status: RESOLVED INCOMPLETE

(Core :: WebRTC: Audio/Video, defect, P5)

Description

[Paul Silaghi, QA [:pauly]]

1:1 call, different networks, http://apprtc.webrtc.org/, nightly 28.0a1 (2013-11-06), win 7 x64 - win 7 x64
The sound is distorted on one side, the same side, no matter if it's the caller or the callee. The behavior is similar to the recording in bug 935617 (https://bugzilla.mozilla.org/attachment.cgi?id=828136)

This is intermittent on a call between Mac OS - Mac OS
And not reproducible on Ubuntu - Ubuntu.

Comment 1

[Paul Silaghi, QA [:pauly]]

This is not repro on Aurora 27.0a2 (2013-11-06), 26 beta 2, but it is repro on Nightly 27.0a1 (2013-09-18) and 26.0a1(2013-09-01). What could be the logic here?

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

Does getUserMedia tests for audio show the same problem?  http://mozilla.github.com/webrtc-landing/gum_test.html

Headset or built-in mic/speakers?  (mic at the sending end, speakers at the receiving end)  What machine?

Can you get a log with signaling:5?

Does it occur 100% of the time on windows, and occasionally on mac?  (That's what's implied above).

What frequency is the mic capturing at?  (See the advanced properties for the device in Sound)

Can you try it in a debug build, with NSPR_LOG_MODULE=mediamanager:5,getusermedia:5,signaling:5

Thanks

Comment 3

[Paul Silaghi, QA [:pauly]]

Attachment: signaling:5 log

Sorry for the delay.

(In reply to Randell Jesup [:jesup] from comment #2)
> Does getUserMedia tests for audio show the same problem? 
> http://mozilla.github.com/webrtc-landing/gum_test.html
No, everything's ok here. Everything is also ok on a local http://apprtc.webrtc.org/ call (even using a proxy from another country). The bug reproduces on a call between two cities.

> Headset or built-in mic/speakers?  (mic at the sending end, speakers at the
> receiving end)  What machine?
Don't exactly understand the question, both caller/callee use headsets(mic+phones)

> Can you get a log with signaling:5?
See attached.
 
> Does it occur 100% of the time on windows, and occasionally on mac?  (That's
> what's implied above).
Yes.

> What frequency is the mic capturing at?  (See the advanced properties for
> the device in Sound)
2 channel, 16 bit, 44100 Hz (CD Quality)

> Can you try it in a debug build, with
> NSPR_LOG_MODULE=mediamanager:5,getusermedia:5,signaling:5
Do you need the logs from here too ? Or just to see if the problem still reproduces? I can't tell for the second part, the debug builds run extremely slow on Windows, not able to support a call at all.

Comment 4

[Petruta Horea [:phorea], Desktop QA]

Reproduced intermittently on a call between Mac OS - Mac OS using the Talkilla provider (https://talkilla.mozillalabs.com/) on Nightly 28.a1 (2013-11-30). There were sound issues on both sides.

Comment 5

[Ada [:adalucinet]]

Reproduced this issue intermittently using https://apprtc.webrtc.org/ on a call between:

Caller: Chrome Stable on Windows XP          
Callee: Firefox 27 beta 7 (Build ID: 20140116125114) on Mac OSX 10.7
_____________________________________________________________________
Caller: Firefox 26.0 on Windows 8
Callee: Firefox 27 beta 7 (Build ID: 20140116125114) on Mac OSX 10.8
_____________________________________________________________________
Caller: Firefox 27 beta 7 (Build ID: 20140116125114) on Mac OSX 10.7
Callee: Chrome Stable on Mac OSX 10.8

The sound is distorted on the callee side for all of the calls.

Comment 6

[u279076]

Thanks Alexandra, can you please also add the information relevant to comment 2?

Comment 7

[Ada [:adalucinet]]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #6)
> Thanks Alexandra, can you please also add the information relevant to comment 2?

> Does getUserMedia tests for audio show the same problem? http://mozilla.github.com/webrtc-landing/gum_test.html
No, it's working ok on Windows 7 and Mac OS X 10.8.
 
> Headset or built-in mic/speakers?  (mic at the sending end, speakers at the
> receiving end)  What machine?
Both caller and callee use headsets.

I'll update with further informations regarding comment 2 first thing on Monday.

Comment 8

[Ada [:adalucinet]]

> Can you get a log with signaling:5?
Please see attached file (signaling log)

> What frequency is the mic capturing at?  (See the advanced properties for the device in Sound)
2 channel, 16 bit, 44100 Hz (CD Quality)

> Can you try it in a debug build, with NSPR_LOG_MODULE=mediamanager:5,getusermedia:5,signaling:5
I've tried with latest Nightly Debug build between Mac OS X 10.8 - Mac OS X 10.7 machines with the following steps:

export NSPR_LOG_MODULES=mediamanager:5,getusermedia:5,signaling:5
export NSPR_LOG_FILE=~/Desktop/log.txt
cd /Applications/FirefoxNightlyDebug.app/Contents/MacOS
./firefox-bin

Are the above steps the correct ones?
Please see attached file for the log (mediamanager:5,getusermedia:5,signaling:5 log)

Comment 9

[Ada [:adalucinet]]

Attachment: signaling log

Comment 10

[Ada [:adalucinet]]

Attachment: mediamanager:5,getusermedia:5,signaling:5 log

Comment 11

[Paul Silaghi, QA [:pauly]]

Attachment: recording.wav

This is how it sounds to me (caller side) on a Win 7 - Win 7 call, nightly 30.0a1 (2014-03-12). The callee could hear me fine.

Comment 12

[u279076]

(In reply to Paul Silaghi, QA [:pauly] from comment #11)
> Created attachment 8390458 [details]
> recording.wav
> 
> This is how it sounds to me (caller side) on a Win 7 - Win 7 call, nightly
> 30.0a1 (2014-03-12). The callee could hear me fine.

Paul, can you see if this reproduces in older Firefox builds? I think our baseline for call quality was Firefox 25 if I recall correctly, but please test back to Firefox 22 where we landed initial support for WebRTC. Lets see if this is a regression and call it as such.

Randell, we're still waiting for your need-info response to comment 11. It's been nearly a month.

Comment 13

[Randell Jesup [:jesup] (needinfo me)]

So something is wrong.  Those NSPR log values should have forced an "Audio device %d allocated" (among many other logs) which does not appear in the logs.  This message has been there since at least October, and likely longer.

Please repeat with debug nightlies and use these values:
NSPR_LOG_MODULES=mediamanager;5,getusermedia:5,signaling:5,webrtc_trace:65535 NSPR_LOG_FILE=whatever WEBRTC_TRACE_FILE=another_file

(added trace logs to verify audio settings)

The test does not have to be long (and the trace log will wrap if it's too long).  Just enough to be sure you've heard the distortion.

Note: I need the logs from the side generating the audio, and from the side receiving the audio as well if at all possible.

Thanks!

Comment 14

[u279076]

Thanks for getting back to us, Randell.

Paul, please follow-up with the information Randell has requested in comment 13.

Comment 15

[Paul Silaghi, QA [:pauly]]

Attachment: Logs.zip

(In reply to Randell Jesup [:jesup] from comment #13)
> Please repeat with debug nightlies and use these values:
> NSPR_LOG_MODULES=mediamanager;5,getusermedia:5,signaling:5,webrtc_trace:
> 65535 NSPR_LOG_FILE=whatever WEBRTC_TRACE_FILE=another_file
The debug builds work so slow on Windows that you won't hear anything but some jerky noises in a 1:1 call. However, I attached the logs from both debug and standard builds, 31.0a1 (2014-04-16), Win 7 x64.

Comment 16

[Paul Silaghi, QA [:pauly]]

I retested this on other machines, same OSes and it doesn't seem to reproduce. I'm inclined to say this is hardware specific. But let's see if anything comes out from the logs in comment 15 first.

Comment 17

[Paul Silaghi, QA [:pauly]]

(In reply to Paul Silaghi, QA [:pauly] from comment #16)
> I retested this on other machines, same OSes and it doesn't seem to
> reproduce. I'm inclined to say this is hardware specific.
I actually found another machine which reproduces the issue.
Randell, do you see anything suspicious in the logs in comment 15?

Comment 18

[Maire Reavy [:mreavy]]

Our best guess is that this is a broken driver for a specific OS/config. If it is due to a broken driver, there's likely little we can do.  I'd like to do a little more investigation (to see if there's a workaround) before we parking-lot this.

Comment 19

[Bulk Bug Changes for mreavy's org]

Mass change P4->P5 to align with new Mozilla triage process.