1497945 - NotReadableError "Failed to allocate audiosource" when calling getUserMedia twice with different deviceId

Status: RESOLVED DUPLICATE of bug 1238038

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

Description

[Iñaki Baz Castillo]

Let's assume we have, at least, two mic inputs in the computer. Then try this code in the console:

```
run();

function run()
{
	console.info('run()');

	let micDevices;

	Promise.resolve()
		// Enumerate mic devices.
		.then(() =>
		{
			console.info('calling enumerateDevices()...');

			return navigator.mediaDevices.enumerateDevices()
				.then((devices) =>
				{
					micDevices =
						devices.filter((device) => device.kind === 'audioinput');

					if (micDevices.length < 2)
					{
						throw new Error(
							'at least 2 audio input devices are needed to reproduce the issue');
					}
				})
		})
		// Use the first microphone.
		.then(() =>
		{
			const firstMicDevice = micDevices[0];

			console.info('calling getUserMedia() with first mic deviceId...');

			return navigator.mediaDevices.getUserMedia(
				{ 
					audio : { deviceId: firstMicDevice.deviceId }
				})
				.then((stream) =>
				{
					// Uncomment this line (it won't fail).
					// stream.getAudioTracks()[0].stop();
				});
		})
		// Use the second microphone.
		.then(() =>
		{
			const secondMicDevice = micDevices[1];

			console.info('calling getUserMedia() with second mic deviceId...');

			return navigator.mediaDevices.getUserMedia(
				{ 
					audio : { deviceId: secondMicDevice.deviceId }
				});
		})
		.then(() =>
		{
			console.info('success!');
		})
		.catch((error) =>
		{
			console.error(error);
		});
}
```

The second call to getUserMedia (with the second mic deviceId) will fail with NotReadableError "Failed to allocate audiosource".

However, if you stop the first track before the second call to getUserMedia, it won'r fail. For that, just uncomment the "stream.getAudioTracks()[0].stop()" line above.

Comment 1

[Philipp Hancke [:fippo]]

potential dupe of https://bugzilla.mozilla.org/show_bug.cgi?id=1238038

Comment 2

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Looks like it to me -- thanks :fippo. ni :padenot to confirm nothing has changed since the last comment[0] on that bug.

[0]: https://bugzilla.mozilla.org/show_bug.cgi?id=1238038#c9

Comment 3

[Paul Adenot (:padenot)]

This is expected for now.

Comment 4

[Iñaki Baz Castillo]

I'd like to say that, as far as I stop the previous mic track, I can do getUserMedia to get the second mic track. But that's not true always.

Question: if the first mic track has been added to a peerconnection and later I call firstTrack.stop() (without doing nothing else in the peerconnection), should I be able to call gUM with the second mic deviceId constraint? Well, in my code it fails with the same error NotReadableError "Failed to allocate audiosource". So, can this be related to the fact that the first mc track is yet part of the peerconnection (even if stopped)? I hope there is no such an annoying "peerconnection & track behavior" relationship, but who knows...

Comment 5

[Iñaki Baz Castillo]

Well, my worst fears have been fulfilled. Yes, what I see is that if the first mic track was added to the peerconnection, later the track is stopped, and a second call to gUM is done by requesting a different mic deviceId, then I get NotReadableError "Failed to allocate audiosource".

This is not a "just use a single mic" limitation, but a bug. The fact that a mic track is being handled by a peerconnection should not change nothing, but it does.

Comment 6

[Iñaki Baz Castillo]

Please, forget previous 2 comments. Indeed I had an additional cloned track of the first mic and it was alive while the second gUM, so the error makes sense.

Comment 7

[Nils Ohlmeier [:drno]]

Do we have a tracking bug we can link this to? If not I think we should have a bug in our backlog to track this work.

Comment 8

[Paul Adenot (:padenot)]

Yes, bug 1238038, as said in comment 1 above.

Comment 9

[Nils Ohlmeier [:drno]]

Alright lets then continue over in bug 1238038.