Closed Bug 936034 Opened 6 years ago Closed 1 year ago

Sound is distorted on one side on 1:1 call

Categories

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

x86_64
Windows 7
defect

Tracking

()

RESOLVED INCOMPLETE
Blocking Flags:

People

(Reporter: pauly, Unassigned, NeedInfo)

References

()

Details

(Whiteboard: [watch][investigation])

Attachments

(5 files)

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.
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?
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
Flags: needinfo?(paul.silaghi)
Attached file 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.
Flags: needinfo?(paul.silaghi)
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.
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.
Thanks Alexandra, can you please also add the information relevant to comment 2?
Flags: needinfo?(alexandra.lucinet)
(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.
Flags: needinfo?(alexandra.lucinet)
> 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)
Attached file signaling log
Flags: needinfo?(rjesup)
Attached audio 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.
(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.
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!
Flags: needinfo?(rjesup)
Thanks for getting back to us, Randell.

Paul, please follow-up with the information Randell has requested in comment 13.
Flags: needinfo?(paul.silaghi)
Attached file 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.
Flags: needinfo?(paul.silaghi)
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.
(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?
Flags: needinfo?(rjesup)
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.
backlog: --- → webRTC+
Rank: 45
Priority: -- → P4
Whiteboard: [watch][investigation]
Mass change P4->P5 to align with new Mozilla triage process.
Priority: P4 → P5
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.