Now AudioInputTrack is the source of the MediaStreamTrack, which is created from getUserMedia at first, to get the microphone data. It has an AudioDataListener member to handle the audio input data from the microphone and an AudioInputProcessing member to apply the audio processing configured by the MediaTrackConstraints.

To make multiple microphones work in the same MediaTrackGraph which is driven by a certain audio device, we need to separate the AudioInputTrack into two tracks:

1. NativeInputTrack
   • handle the audio input data from the microphone
2. AudioProcessingTrack:
   • is the source of the MediaStreamTrack
   • apply the audio processing configured by the MediaTrackConstraints for the MediaStreamTrack

and they will be linked via a MediaInputPort

By doing so, the AudioProcessingTrack, which is paired to a MediaStreamTrack, can use a different source track than the NativeInputTrack when we are able to open another microphone in the MediaTrackGraph, if the user asks to create another MediaStreamTrack from another microphone device

Draft will be on this branch. The below commits will be updated from times to times here:

• Absorb mInputDeviceUsers into NativeInputTrack
• TODO: Replace mInputDeviceUsers by mConsumers[i]->GetDestination()

Replace mInputDeviceUsers by a <device-id, NativeInputTrack> map

Remove mDataUsers in NativeInputTrack. We can deliver audio data
via NativeInputTrack's data consumer tracks directly.

This patch demonstrates a way to deliver audio data from NativeInputTrack to AudioInputTrack from MediaInputPort directly, without using a nsTArray<RefPtr<AudioDataListener>> list to track the data receiver in AudioInputTrack. However, we need to make sure the AudioInputTrack::CloseAudioInputis called before the MediaInputPort is destroyed and we will use raw pointers all the times. I am not sure if it's a good way to go now.

Depends on D113680

The final goal is to get the input audio data from MediaInputPort, so we
move the data receiving and processing from NotifyInputData to
ProcessInput, which is a new function created in this patch.

Backed out 3 changesets (Bug 1702646) for causing gtest failures CLOSED TREE

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&collapsedPushes=842382&selectedTaskRun=LOW_f5pISo6DS9liWJjsiw.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=2b5f35e21e84a3310fd6f238cb79469ffc325ec2

Log: https://treeherder.mozilla.org/logviewer?job_id=341513992&repo=autoland&lineNumber=4035
https://treeherder.mozilla.org/logviewer?job_id=341513233&repo=autoland&lineNumber=30166

Backout: https://hg.mozilla.org/integration/autoland/rev/f59d5e60aee16f7e34d9dd160efeef8cea3da835

The AudioInputProcessing now needs to call ProcessInput to process the
given input data instead of processing them in NotifyInputData

Add an utility function named AppendFromInterleavedBuffer in
AudioSegment to append data from the given interleaved buffer. This
function does the same job as what AudioInputProcessing::InsertInGraph
and NativeInputTrack::ProcessInput were used to do. As a result, these
two functions can be eliminated or simplified.

Depends on D116673

(In reply to Noemi Erli[:noemi_erli] from comment #7)

Log: https://treeherder.mozilla.org/logviewer?job_id=341513992&repo=autoland&lineNumber=4035

The following crash is expected. Do not panic.

./mach gtest PLDHashTableTest.InitCapacityOk intends to cause crashes. Nothing needs to worry about here ( Do not panic ;) ). In addition, I don't think my code touches any hash-table implementation.

https://treeherder.mozilla.org/logviewer?job_id=341513233&repo=autoland&lineNumber=30166

This is the only thing we should take care of. D116673 should fix the problem.

https://hg.mozilla.org/mozilla-central/rev/dad561cb1cfb
https://hg.mozilla.org/mozilla-central/rev/98aad7de92bf
https://hg.mozilla.org/mozilla-central/rev/303bfb969f52
https://hg.mozilla.org/mozilla-central/rev/c450c5d35c61
https://hg.mozilla.org/mozilla-central/rev/f0c736218ab6