Setting OSX audio to "4 ch 24-bit integer 44.1 kHz" causes permanent "NotReadableError: Failed to allocate audiosource" in Firefox

RESOLVED FIXED in Firefox 57

Status

()

Core
WebRTC: Audio/Video
P1
major
Rank:
14
RESOLVED FIXED
5 months ago
5 months ago

People

(Reporter: jib, Assigned: achronop)

Tracking

(Depends on: 1 bug)

unspecified
mozilla57
Unspecified
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox57 fixed)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(2 attachments)

STRs rely on starting in a specific failure state:

1. Occasionally, after reopening my MBP lid having used getUserMedia, camera stops working across OSX.
   Neither, Chrome, Firefox, nor Photo Booth work, and http://jsfiddle.net/jib1/pz5pynyf/ says:

     "NotReadableError: Failed to allocate videosource" (note VIDEO)

2. To get out of this state, I type: sudo killall VDCAssistant
   Photo Booth instantly starts working, Chrome works once I refresh the fiddle, but Firefox says:

     "NotReadableError: Failed to allocate audiosource" (now it says AUDIO!)

3. If I do {video: true, audio: false} then the camera works fine, only audio is hosed.
   Even restarting Firefox did not get me out of this funk.

Fortunately, this meant I could debug it, which I did. MOZ_LOG output shows the failure:

  [MediaManager]: D/MediaManager Audio config: aec: 1, agc: -1, noise: 1, delay: 10, channels: 4
  [MediaManager]: D/MediaManager AllocChannel: sampling rate 32000
  [MediaManager]: D/MediaManager Audio device is not initalized
  [MediaManager]: D/MediaManager Failed to allocate audiosource 2147500037

In the debugger I see it failing here [1]:

    if ((codec.channels != 1) && (codec.channels != 2)) {
=>    _shared->SetLastError(VE_INVALID_ARGUMENT, kTraceError,
                            "SetSendCodec() invalid number of channels");
      return -1;
    }

because codec.channels is 4. It got set to 4 one step up on the stack here [2]:

          uint32_t maxChannels = 0;
          if (mAudioInput->GetMaxAvailableChannels(maxChannels) == 0) {
            codec.channels = maxChannels; // <-- maxChannels is 4
          }
          ...
=>        if (!ptrVoECodec->SetSendCodec(mChannel, codec)) {

I suspect this broke in bug 971528 or bug 1213414 which touched GetMaxAvailableChannels().

I have no idea why this doesn't fail all the time, other than that the stack must be unusual somwhow in this particular state. 

[1] https://dxr.mozilla.org/mozilla-central/rev/1867d7931c0a70ab90edf4aa84876525773a7139/media/webrtc/trunk/webrtc/voice_engine/voe_codec_impl.cc#82
[2] https://dxr.mozilla.org/mozilla-central/rev/1867d7931c0a70ab90edf4aa84876525773a7139/dom/media/webrtc/MediaEngineWebRTCAudio.cpp#837

MediaManager (121)#0	0x00000001088f875b in webrtc::VoECodecImpl::SetSendCodec(int, webrtc::CodecInst const&) at /Users/Jan/moz/mozilla-central/media/webrtc/trunk/webrtc/voice_engine/voe_codec_impl.cc:82
#1	0x00000001057c2b68 in mozilla::MediaEngineWebRTCMicrophoneSource::AllocChannel() at /Users/Jan/moz/mozilla-central/dom/media/webrtc/MediaEngineWebRTCAudio.cpp:845
#2	0x00000001057c1b92 in mozilla::MediaEngineWebRTCMicrophoneSource::UpdateSingleSource(mozilla::MediaEngineSource::AllocationHandle const*, mozilla::NormalizedConstraints const&, mozilla::MediaEnginePrefs const&, nsString const&, char const**) at /Users/Jan/moz/mozilla-central/dom/media/webrtc/MediaEngineWebRTCAudio.cpp:319
#3	0x00000001057acb79 in mozilla::MediaEngineSource::ReevaluateAllocation(mozilla::MediaEngineSource::AllocationHandle*, mozilla::NormalizedConstraints*, mozilla::MediaEnginePrefs const&, nsString const&, char const**) at /Users/Jan/moz/mozilla-central/dom/media/webrtc/MediaEngine.h:426
#4	0x00000001057abc7e in mozilla::MediaEngineSource::Allocate(mozilla::dom::MediaTrackConstraints const&, mozilla::MediaEnginePrefs const&, nsString const&, mozilla::ipc::PrincipalInfo const&, mozilla::MediaEngineSource::AllocationHandle**, char const**) at /Users/Jan/moz/mozilla-central/dom/media/webrtc/MediaEngine.h:337
#5	0x00000001052e5723 in mozilla::MediaDevice::Allocate(mozilla::dom::MediaTrackConstraints const&, mozilla::MediaEnginePrefs const&, mozilla::ipc::PrincipalInfo const&, char const**) at /Users/Jan/moz/mozilla-central/dom/media/MediaManager.cpp:892
#6	0x0000000105377090 in mozilla::GetUserMediaTask::Run() at /Users/Jan/moz/mozilla-central/dom/media/MediaManager.cpp:1507
#7	0x00000001016a70ed in nsThread::ProcessNextEvent(bool, bool*) at /Users/Jan/moz/mozilla-central/xpcom/threads/nsThread.cpp:1033
#8	0x00000001016aa89c in NS_ProcessNextEvent(nsIThread*, bool) at /Users/Jan/moz/mozilla-central/xpcom/threads/nsThreadUtils.cpp:521
#9	0x00000001021202c6 in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) at /Users/Jan/moz/mozilla-central/ipc/glue/MessagePump.cpp:369
#10	0x0000000101ffbec5 in MessageLoop::RunInternal() at /Users/Jan/moz/mozilla-central/ipc/chromium/src/base/message_loop.cc:326
#11	0x0000000101ffbe25 in MessageLoop::RunHandler() at /Users/Jan/moz/mozilla-central/ipc/chromium/src/base/message_loop.cc:319
#12	0x0000000101ffbdcd in MessageLoop::Run() at /Users/Jan/moz/mozilla-central/ipc/chromium/src/base/message_loop.cc:299
#13	0x000000010204ba14 in base::Thread::ThreadMain() at /Users/Jan/moz/mozilla-central/ipc/chromium/src/base/thread.cc:181
#14	0x0000000102007fce in ThreadFunc(void*) at /Users/Jan/moz/mozilla-central/ipc/chromium/src/base/platform_thread_posix.cc:38
#15	0x0000000100199c50 in _pthread_body ()
#16	0x0000000100199b9c in _pthread_start ()
#17	0x0000000100199385 in thread_start ()

I suspect this affects linux as well (bug 1379511 looks suspiciously similar), but I've only reproduced it on OSX.
Hmm, apparently getUserMedia({audio:true}) has stopped working permanently for me in Firefox. Regression range: bug 971528

10:13.30 INFO: Last good revision: 00f292748b3e702f338589863b986f2ee50d55cf
10:13.30 INFO: First bad revision: 73260f7c6dae11039cc4c738ac8714671d8cd1df
10:13.30 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=00f292748b3e702f338589863b986f2ee50d55cf&tochange=73260f7c6dae11039cc4c738ac8714671d8cd1df

I'm not exactly sure what changed with my system. I've reset the machine to no avail. Any tips on how to reset things?

The problem is limited to the internal mic. If I attach my Logitech c920 and chose its microphone in the prompt then that works.
Blocks: 971528
No longer blocks: 1213414
Rank: 14
Flags: needinfo?(achronop)
(Assignee)

Comment 2

5 months ago
It is very strange that the internal mic reports 4 channels. Can you get logs to verify that. I guess your c920 camera reports 2 channels and that's why it works.

I need to discuss again with Paul the decision to provide all available channels in the input since we are not ready for anything more than stereo in webrtc code.
In /Applications/Utilities/Audio\ MIDI\ Setup.app/ the "Format" field had somehow been set to "4 ch 24-bit integer 44.1 kHz".

When I set it back to 2 channels, everything works again.

I can reproduce easily now:

Setting it to "4 ch 24-bit integer 44.1 kHz" causes "NotReadableError: Failed to allocate audiosource" in Firefox.
(Reporter)

Updated

5 months ago
Summary: Firefox won't recover from "NotReadableError: Failed to allocate audiosource" after sudo killall VDCAssistant → Setting OSX audio to "4 ch 24-bit integer 44.1 kHz" causes permanent "NotReadableError: Failed to allocate audiosource" in Firefox
(Assignee)

Updated

5 months ago
Depends on: 1393401
(Assignee)

Comment 4

5 months ago
Created attachment 8902319 [details] [diff] [review]
WIP: Fix input for more than 2 channels

:jib or :padenot can you test it with a real 4-channel device. It works locally but I use soundflower which means I cannot hear anything in order to verify the quality of the audio.
Flags: needinfo?(achronop) → needinfo?(jib)
Attachment #8902319 - Flags: feedback?(padenot)
(Assignee)

Updated

5 months ago
Assignee: nobody → achronop
(Assignee)

Comment 5

5 months ago
:padenot the important thing to note is that we do not downmix when processing is disabled (PassThrough). In that case we deliver all channels. If any of AEC/NS/AGC is on then we downmix to stereo.
It no longer fails when I set it to "4 ch 24-bit integer 44.1 kHz" or ""4 ch 16-bit integer 44.1 kHz",

But there's a sharp buzzing bee type of humming noise in those modes. Sometimes I can hear myself snapping fingers over it, sometimes even that seems clipped or muted, but the sound is definitely messed up.
Flags: needinfo?(jib)
Some more info:

When I open https://blog.mozilla.org/webrtc/fiddle-of-the-week-audio-constraints/ using the same setup, then I get the same humming noise, but when I turn off echo cancellation and noise suppression in the fiddle then the hum goes away, but the audio is now delayed by several seconds, and the frequency is lower, similar to symptoms I've experienced in the past with similar bugs.
jib, starting with the right constaints instead of switching will allow you to diagnose this.

Updated

5 months ago
Attachment #8902319 - Flags: feedback?(padenot)

Comment 10

5 months ago
I think I have run into this same issue. I am permanently unable to do getUserMedia({audio:true}) on my Mac. This appears to be a regression because Firefox ESR (52) works fine but Firefox stable, beta and nightly all have this same issue. I get "NotReadableError Failed to allocate audiosource".
Comment hidden (mozreview-request)

Comment 12

5 months ago
mozreview-review
Comment on attachment 8904514 [details]
Bug 1392837 - Support multichannel audio input on gUM.

https://reviewboard.mozilla.org/r/176366/#review181256
Attachment #8904514 - Flags: review?(padenot) → review+

Comment 13

5 months ago
Pushed by paul@paul.cx:
https://hg.mozilla.org/integration/autoland/rev/ed4d0bcad1da
Support multichannel audio input on gUM. r=padenot
https://hg.mozilla.org/mozilla-central/rev/ed4d0bcad1da
Status: NEW → RESOLVED
Last Resolved: 5 months ago
status-firefox57: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
You need to log in before you can comment on or make changes to this bug.